Should I use a WPF converter or trigger?

I was wondering how you decide when to use converters and when to use triggers . I prefer to use triggers for operations with the graphical interface (for example, show / hide controls, change their appearance, etc.).

Some time ago I used the BooleanToVisibilityConverter for this purpose, but now I just don’t need it, I connect everything to visibility using triggers, and I even started thinking: "What was the purpose of creating the BooleanToVisibilityConverter command with the MS command?" As a rule, when possible, I try to use a declarative way to write code - in this example - XAML.

How do you feel about this?

+8
triggers converter wpf xaml
source share
5 answers

I agree with you, I am also trying to use declarative code in XAML and prefer Triggers over Converters .

In most scenarios, triggers can do the same job as any converter, but Converters can have the user / business logic mentioned in pchajer.

One limitation of Triggers is that Setters in your DataTriggers can change the properties of your user interface elements; therefore, you cannot update the ViewModels property with triggers , that is, Converters win, remember the ConvertBack method.

So, you can associate your VM property with Visibility controls using the BooleanToVisibilityConverter , and even if your Visibility controls are changed by other means, your VM property will be updated ; it is usually not required why BooleanToVisibilityConverter is replaced by triggers.

So, in short -

Triggers can only perform OneWay operations, while Converters can only perform TwoWay operations

+13
source share

In my opinion, you look from the bottom up, and you just need to look from top to bottom.

Triggers - When the specified condition is met, it starts execution

Converters - convert between two incompatible types.

Why do we need a logical data type when we can perform the same functionality with intergers?

+2
source share

You can achieve functionality either using a trigger or from a converter, but from my option below the possibility can be considered when making a decision

  • If you use the TDD approach for development, go to the converters, as you can write test cases.
  • If there is any business logic, it is better to edit the code in the converter and sometiems that cannot be achieved using the trigger.
+1
source share

In addition to what was said above, I can only add:

  • Triggers sometimes require duplication of things, for example. when you have several properties for triggers, you need to specify each combination
  • Sometimes you will need code to correctly convert from type A to B, then you will have to use converters. Triggers are good if the value / property is already open from the VM, so you can use it for triggers.
+1
source share

You should always perform business-related operations in DomainModel objects, or at least in a ViewModel. To do some business work in the converter is not a good option, because Converters are designed to convert values ​​from one type to another.

0
source share

All Articles