May include but is not limited to: creating a storyboard, controlling timelines, controlling the behavior when the animation completes, double, color, and point animations; start an animation from code and from XAML.
I have wonderful news for you; this will be the last post from this objective (Building a User Interface by Using Basic Techniques). Then we’ll switch levels and head for the advanced UI! But until then, we have the topic of animations.
So what is an animation? You can think of it like a stop-motion movie, and you’d be far from the WPF truth. An animation in WPF is just the change of a dependency property over a certain amount of time. So it’s not frame-based, but property-based. This has pros and cons, like anything else in life. The pros are so numerous that I can’t this pathetic blog post wouldn’t be enough for them, so let’s focus on that one little con. That is simply you can’t make a WPF animation (at least not a canned, out-of-the-box one) that doesn’t involve changing a property (let’s say, you’d like to add some elements dynamically). But why would you even bother thinking on such nonsense?
There are two types of animation in WPF – linear animations and key frame animations. Fortunately, we won’t use key frame animations, simply because they aren’t tested here. And there are an awful lot of classes dealing with animations, such as DoubleAnimation and ColorAnimation. Of course, we have Int16Animation, Int32Animation and Int64Animation, to deal with int properties. Now how to do animations? In code, you can do this: Continue reading
May include but is not limited to: fonts, styles, data sources, images, resource dictionaries, resource-only DLLs
This topic goes hand in hand with the previous one (Styles), so I suggest you to read that one too. Resources are reusable elements in your application stored in some kind of repositories (in a DLL, in a resource collection, etc.). Let’s start with resource collections. These tools are found everywhere in the framework, mostly because the class FrameworkElement exposes a property called Resources, which is an instance of ResourceDictionary. You can imagine a resource dictionary: it holds a lot of resources, which are identified by a key (dictionary = a collection of keys + values). That’s why the all your resources should use a Key property (and in a dictionary, all of them should use a different one).
The most frequent place to store resources is the Window.Resources section. You can use static and dynamic resources. Let’s stick with static, When you use these, you must define the resource before the place you refer it. When you refer it, the framework starts a recursive search up the element tree to find the resource by the specified key. You should be aware of that the first resource will be used – that is the closest to the element that uses it. Continue reading
May include but is not limited to: application-level styles, style inheritance, Generic.xaml, theming attributes
I think that all of us would agree that there’s few duller things than creating styles for an application (at least I always feel that), but fortunately people designing exams thought that we should be able to do so – so I have no exception, I just write a post about it.
If you ever caught yourself copy-pasting some piece of xaml into every textbox or button on a form (I’ve done so, e.g.: HorizontalAlignment=”Center” Margin=”0, 0, 5, 5”), than you are doing it wrong. The proper way to do so is applying styles. You can do so at many levels, and the control level is just one – but not so shockingly, it will override the other levels.
Now the solution for your problem (in fact, one of the solutions) is called styles. What’s a style, you could ask. It’s a class with a few properties, which are as follows: Continue reading
May include but is not limited to: using panel-derived controls, attaching properties
OK, as I promised, let’s get into the WPF business. As you may already know, WPF is a revolutionary UI system. It is revolutionary, because it breaks up with the messy, evil, sluggish, hellish, whatever bad property you can invent here, way of handling the screen real estate (you know, win32 and GDI+), and takes it to a new level where you can create a localization friendly UI which supports all possible screen sizes equally well, just by thinking of it, with the sacred milcore.dll.
OK, I hope you spot the irony up there. But WPF is in fact revolutionary in handling UI rendering and a lot of things, but it isn’t that easy. Especially if you are, like me, the guy who drags some controls into a form, and call that a UI. You can of course drag controls in the designer to a form, but surprisingly, that does the things WPF was made to fight with: hard-coding coordinates (OK, the coordinates won’t get hard coded, but their margin property will), so forgot the crappy designer built into VS and write XAML by hand, like real coders do! (Irony +1). Continue reading