For the past several months, my WPF learning experience has been a steep curve; stepping far ahead from Windows Forms. At first, I thought it would be as easy as learning Windows Forms. But it turned out that I was wrong :D. The deeper I dig, the more challenging it is.
I think there are couple of things I've learned so far that I'd like to share here. Please note that this post is a highly overview. Do think of it as you are viewing an island from a helicopter or plane far above it (the 'helicopter view' term, right?). The details can be saved for later (in the form of questions, feedbacks, or later posts, I think :)).
OK, so here they are.
From [code] to [XAML and code] and from [XAML and code] to [XAML versus code]
NOTE: code here refers to programming code.
There was no declarative presentation language to be used with Windows Forms before XAML, at least in my experience with it so far. Its UI representations are all made using code. However, in WPF things are quite different now with the introduction of XAML (although XAML can also be used to define a Windows Forms application, but that's not the case before it).
XAML stands for eXtensible Application Markup Language (and I won't go explaining it in details here.) Basically, it's just a declarative language since it's an XML. But in WPF, it goes further to be used to define UI representations (UI structures). More or less, it's sort of similar with HTML or ASP.NET language in web-based application development. The point is that the UI representations can now be written using XAML and/or code. Further, it can be easily leveraged into an MV (Model-View) pattern (I haven't explored the C (Controller) part yet to make it MVC completely).
Next, after its diverse approach invented (XAML and code), an obvious question approach arises in my mind: when to use XAML and when to use code? I haven't had an exact guide on this yet, especially since I'm currently stuck dealing with UI visual inheritance using WPF (visual) designer and it seems there is still no proper solution. So, I use both interchangeably, depends on the need.
NOTE: UI visual inheritance is still challenging both in Windows Forms and WPF when using their own (visual) designers. In Windows Forms, you can use visual inheritance in its designer with limitation (on changing a base control's properties' value). In WPF, I have no idea and I'm still struggling for it. A workaround I can think of is by using user control (same as in Windows Forms) or just copy-paste the same XAML block over different Windows/Pages but it's still not a visual inheritance :(.
From a procedural-based perspective (Windows Forms) to a property-based one (WPF)
An obvious example of procedural-based perspective in Windows Forms is the use of OnPaint(). It is a completely a different approach compared to the use of dependency property in WPF. The latter is closer to the object-oriented mind set. With OnPaint(), it ends up with writing all presentation logics in one big step by checking every possible UI states. Yet, it's simply complex.
NOTE: I've never written any Windows Forms-based controls nor user controls from the scratch; and never intended to but already modified existing ones (it's even if and only if really really necessary). So, my statement above should be considered as an approximation based on my analysis of codes written by others.
Further, I think the former is a centralized approach compared to the latter, which is a decentralized and distributed one. However, the latter approach could also make life harder if not carefully used, especially when writing a new derived control (or user control). I'm especially still digging in this area and it is challenging so far. And it definitely blows my mind!
From a property to a dependency property
At my first glimpse of a dependency property, it just looked like an standard and ordinary property, although I was confused with the 'dependency' term for awhile. When in the code mode (as opposed to in the XAML mode), it still has the get and set methods. Its (suggested) implementation is quite different but in a consistent manner across all others.
Using C# 2.0, a property's declaration looks like this:
1: private bool _isReadOnly;
2:
3: public bool IsReadOnly
4: { 5: get { return this._isReadOnly; } 6: set { this._isReadOnly = value; } 7: }
While a dependency property's declaration looks like this:
1: public static readonly DependencyProperty IsReadOnlyProperty = DependencyProperty.Register("IsReadOnly", typeof (bool), typeof (DerivedButton)); 2:
3: public bool IsReadOnly
4: { 5: get { return (bool) base.GetValue(IsReadOnlyProperty); } 6: set { base.SetValue(IsReadOnlyProperty, value); } 7: }
Wow! So now, it doesn't look as simple as an ordinary property's declaration, right? Two important things I notice with a dependency property are (1) there is now a static field used for its metadata definition (including its type, the owner's type, and some others, such as its default value and more including property handler methods (defines the property's behavior)), and (2) there's no field should be used as a back field since it's now replaced with the use of base.GetValue() and base.SetValue() methods, derived from DependencyObject class.
Of course, a dependency property is much deeper than the above explanation, for the reasons it has to be invented other than using a (standard) property. One important thing I note is that a property triggers behaviors, especially when its value is changed. Thus, there are behaviors depend on its value and are also triggered by. That's what I think about why it's named 'dependency property'.
Closing thoughts
I think those are some important things I have been learning after dealing with WPF up until now. There are many others but I think they are enough for now. They no need to be summarized. Up until now, I do still think it takes some (or maybe a lot time) for me to switch into the WPF mind set and it's a really huge step for me.
I'm just in the middle of the journey and I still learn a lot. I think WPF is a very great stuff and has been being prepared for the next generation of UI on Windows platforms (as its name implies: Windows Presentation Foundation), though it has been still immature. And I can't wait for the next WPF improvement Microsoft will bring in the .NET Framework 4.0.