sorry Phil. But I think most of this I can't do with XAML. Rememeber: All you can do in XAML, you can do in code too, but the reverse is not true. Using factories to simulate and test the GUI for example. But no, I don't do it now, but I could.
All that XAML does is facilitate the 'hooking up' of the 'ViewModel' to the 'View'. (The way I use it.)
For MVVM guys there is nothing I have found that can't be done easily in XAML, and, it usually takes little script to do it.
After all, that is what the XAML stands for - "XML based Application Mark-up Language". SO I use it for 'Mark-Up'.
I copy and paste the UI script from other XAML samples, it is very quick and easy, once you know what you are doing and trying to achieve. I am one of the converted (few) "haters become lovers". It certainly is not rocket science the way I use it.
The XAML script required for MVVM and Data Binding is much simpler to understand than people first think - they panic! Yes, you can find on the web many other XAML samples that even I can't begin to understand, but then programmers could always do that to any language I have found over the years.
I once gave a conference session on "WPF without XAML" - 'DevShare' some 7 years back I think - but since then I have come to realise just how quick and easy development of MVVM GUI is with XAML - I tell no lies, I 100% believe what I say ;-0)
AND- the rule is Public Properties in the VM and then XAML to specify the bindings - then Data Binding works, every time.
XAML mark-up comes a close second to Unit Testing on the 'should do' list.
yes, you can do yearly all you need in XAML, but very often it is simplier in code.
I'm doing all my screens in pure code (X#) too - sometimes it is a bit hard to find the right syntax, but with subclassed controls WPF shows its real power. And inheritance is important also for views - to reuse code.
And another issue: IMHO to make very good WPF forms you need to think first how the window/form/view needs to behave in a resizing process - a very important issue with the changing screen sizes today, ranging from 1280x800 to at least 1920x1080 if not 4K.
At this point I think it is better to work in code with enhanced classes.
exactly this is evil: it violates the DRY principle.
XAML is static, code is (can be) dynamic.
I started using XAML in a small app. I hate using designers (programs) in general. It's for designers (humens), not for coders like me. And this is why XAML was invented for: To let designers (humans) design without knowing anything about computer languages. And this kind of teamwork is where XAML can play an important role.
In all other environment, saying one man shows like me, you are free in your decision.
I have to say that of course using expression blend shows me whats possible with WPF. But this drag and drop, copy and paste ... grrrrh.
I have to make the confession that when I do my coding, in the X# editor, I copy and paste, drag and drop, all the time. Always have done.
So now I know why my programs never work, always fail .......... because I am evil !
Because the XAML drives the UI in the designer, AND, the designer changes drive the XAML script, copying and pasting script is so easy. Like getting the standard attributes and settings for a 'DataGrid' control - easy-peasy ;-0))
Me thinks that both you and Wolfgang's strong views are based on the fact that you both are scared of Visual Studio ;-0)
Oh! and what is wrong with design, and even designers for that matter. My daughter is a designer, and a nice person she is for sure !
at least I am not scared of Visual Studio - I feel only more "at home" in XIDE. Sometimes I have to work also in Visual Studio (when I need to work with the Google AdWords API), but XIDE is much more like the VO IDE.
I don't like XAML at all (as I don't like HTML <g>), and I prefer cleanly written code to any markup language - maybe because I'm a programmer and not a designer.
Developing a view in X# code instead of writing it in XAML gives me much, much more liberty. So I can define the columns of a DataGrid by DataBinding in the ViewModel (because they need to be configurable by the user), and can display only the significant input controls on the screen instead wasting space like in VO by hiding controls.
Of course these are personal preferences and I would not like to impose them of someone other (excluding my own company of course - there I'm setting the standards.)