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”;
Continue reading “Add multimedia content to an application in WPF”
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. Continue reading “Implement user-defined controls”
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: Continue reading “Modify the visual interface at run time”
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: Continue reading “Configure WPF commanding”
May include but is not limited to: tunneling vs. bubbling events, handling and cancelling events
OK, this is probably more interesting than building an animation, so let’s begin! I guess every one of us got this far is fairly familiar with events. They are everywhere (especially if you use ASP.NET WebForms); but what is that ugly routed word before them? It’s simpler than you might imagine first. A routed event is an event that can be catch and (or) handled on an element that didn’t fire it (but there should be some relation). Imagine a click to a button. You can handle that click on the button level, but if a button is inside a grid, and then you can handle the click on the grid level, or even at the window level. I used the word handle, but it’s a little misleading. It suggests that the event is finished, gone for good after you make it trigger some event handler. Now this is not necessarily the case, you can handle a routed event multiple times in multiple places.
The previous paragraph became too long, so I start a new one. There are two types of routed events (I think everything starts to have two types) tunneling events which goes down to the hierarchy (like any tunnel) and is start from the Window (or the topmost container). The other type is bubbling event, which goes up in the hierarchy like a bubble (but it’s not falling back sometimes). Continue reading “Manage routed events in WPF”