May include but is not limited to: implementing INotifyPropertyChanged, using INotifyCollectionChanged(ObservableCollection)
We’ve discussed that WPF has some nice data-binding support which lets us implement two-way bindings. But it won’t work from itself, especially not for you domain classes. If you’d like to receive change notification support, then you need an interface what will do just that for you. It’s called INotifyPropertyChanged, and exposes one event, with the following signature:
public event PropertyChangedEventHandler PropertyChanged;
It’s up to you to fire this event whenever one of your properties changes. A decent example: Read More…
May include but is not limited to: binding options, static and dynamic resources, element bindings, setting the correct binding mode and update mode, binding to nullable values
I think one of the biggest points in WPF is data binding. It’s incredibly easy to bind a form or a list to an object or to a collection of objects. You just set the container’s DataContext property to your custom object, set up the XAML markup and you have bound your data.
But the Binding class has so many properties you can set that it’s easy to get lost. I’ll show you some properties used in basic data binding scenarios:
- Mode: the binding mode to use. It has five potential values, which are:
- TwoWay: updates the target property or the property whenever either of them changed.
- OneWay: update the target property whenever the source property changed.
- OneTime: updates the target property only at startup, or when you change the underlying DataContext.
- OneWayToSource: updates the source property whenever the target property changed.
- Default: delegates the task to handle binding changes to the target properties target. User-editable properties usually have two-way bindings, others usually have one-way bindings. But exceptions occur.
- Path: the path of the property to bind to, such as TextBox.Text.
- StringFormat: when the target property is a string, you can set its format. It is like a Converter, but on a much more basic level.
- TargetNullValue: if you bind to a nullable value which happens to be null, you can specify another value to bind to. If you’d like to show a static text, like “Value is null”, you need to wrap it between parentheses.
- UpdateSourceTrigger: it defines the time to bind. The default value is LostFocus, which means that the property gets bound when the focus is lost (you navigate further). Other possible values are explicit (binding only occurs when you call it from code) or PropertyChanged, which updates the binding in the moment of a property change.
So that’s all you need to know about the Binding class for now. It’s worth knowing that you can bind elements together. It hasn’t got much sense, but for example, you can bind together a TextBox and a Slider. Then if you move the slider, your textbox will be updated – or if you type in text, the slider will jump to that position (of course if you set up the binding this way).
May include but is not limited to: implementing custom value converters, implementing multivalue converters
Once I wrote a WPF blog management tool, and as all of us know, blog posts tend to have tags. These tags can tremendously facilitate navigation by letting you find related contents in a matter of seconds. But how would you work with them from a management point of view.
I bound my form to a Post object, which had a collection of TagPost objects (IEnumerable<TagPost>) a TagPost is just a switchtable between Posts and Tags with a unique ID. I decided to visualize tags as a comma-delimited list, like this:
WPF, 70-511, Exam
But I had a collection of TagPost, which didn’t look like this. How could I do this without messing my data binding code (which happened to be one statement)? The answer was using value converters.
A value converter is a class that implements the IValueConverter interface. It has two methods returning Object, Convert and ConvertBack, which take the following parameters (both of them): Read More…
May include but is not limited to: media player vs. media element; adding a sound player; images
The .NET Framework is baaad at media support. When I tried to stick together a simple application in 2.0 which managed sounds, I had to find out that it’s not built with that in mind. However, WPF has far more capabilities then did Windows Forms, so let’s find out how to create hardcore visual and audio effects!
The first thing you can try is the SoundPlayer. You won’t like it, neither did I. It can only play .wav files (and only in pcm format). Anyway, if you are the pcm wav player guy then you could do as follows:
SoundPlayer sp = new SoundPlayer();
sp.SoundLocation = “my.wav”;
May include but is not limited to: deciding whether to use a user/composite, extended, or custom control; creating a user/composite control; extending from an existing control
This is another area where the WPF control model and the ASP.NET control model overlaps closely. As you can remember (it was posted on this blog) in ASP.NET there are custom controls (they can be installed into the toolbox and dragged from there to the form, and they are the basic unit of encapsulation) and user controls, which are made for a single application, by composing some existing controls together. This stands for WPF as well.
MS exams aren’t very good at custom controls (I think they are too complicated to test). This objective has it written too that you don’t have to implement a custom control by writing code. Huh, we got our asses saved, no code writing! Just stick close to XAML and no harm can come to you. So we have to decide when we will use which type of controls. I think those questions contain their answers as well – when you need something duct-taped together, write a user defined control. If you need some robust piece of functionality – write a custom control. If you need just one more thing to add (a blinking tooltip) just extend the ToolTip class – these are pretty straightforward. Read More…
May include but is not limited to: adding/removing controls at run time; manipulating the visual tree; control life cycle; generating a template dynamically
I’m a little bit confused about this topic, because it seems so simple, yet you can run into very difficult things here. In WPF, things can get complicated quite soon (compared to, for example ASP.NET). One such thing is the difference between logical and visual trees.
Every WPF element is composed of a whole bunch of other elements (which in turn are WPF elements as well). For example, the Button class uses heavily the decorator pattern, and there is a ButtonChrome class involved, and a ContentPresenter – which can load other elements into one, and the rest. So the logical tree for a Button is simple – Button with a text of String. Yet the visual tree is much more complicated. You can dig deeper into the topic by examining these trees with LogicalTreeHelper and VisualTreeHelper classes.
Now how would you add a control at run time? I’d do the following: Read More…
May include but is not limited to: defining WPF commands based on RouteCommand; associating commands to controls; handling commands; command bindings; input gestures
To understand commands, I think the best way is to fire up, let’s say Word, and have a look around the UI and search for tasks. For example, when you’d like to undo something, you have a variety of choices: press Ctlr + Z, or right click to get a context menu, and click the undo command. You can even hit undo on the ribbon, and there are certainly various elements that you can call to get the same result done.
Of course, you can implement this functionality by using a switchboard-like code-behind class – you factor out the undo logic, and call it from a variety of event handlers. But what if you have an undo icon, and you can’t undo anything more. Then the icon should be disabled, doesn’t it? Here comes the WPF command system into picture.
A command in WPF is a class that implements the ICommand interface. This interface is quite simple, it has two methods and an event, as follows: Read More…