If there's going to be code that's driven by a UI event, I tend to expose a
Func<> or Action<> on the ViewModel that encompasses the behaviour and call
it in the code behind.

 

Well yeah, I do that as well, but I'm writing a new app and I want it to be
"right" and a good example so I'm trying really hard to obey MVVM patterns.
I'm trying too hard obviously.

 

And remember one of the golden rules; if it's taking too long you're
probably not doing it right.

 

That adage died a few years ago.

 

The things I'm "doing" are perfectly sensible and expected in the UI of a
modern app. Here are some example stumbling blocks:

 

~1 hour = Find really obscure XAML markup to allow commands to fire from
ContextMenu and bubble to the Window.

~1 hour = Find KeyDown binding trick for TreeView.

~2 hours = Place different ContextMenus on different TreeView nodes and get
them to not bubble to other nodes. This required delicate right-click
processing.

~1.5 hours = Convert an Icon in a resx file into an ImageSource with correct
transparency.

~0.5 hours = A 16x16 image is displayed the size of a matchbox for no
apparent reason.

~0.5 hours = Markup extension doesn't set Text of <Run> due to different
class hierarchy.

~0.5 hours = DataTemplate not applied in ListBox unless bound to collection.

 

There are many dozens of other smaller "glitches" I have stumbled across in
the last week, each takes 10-15 minutes to solve. Over the weeks these
glitches add up to an astonishing amount of wasted time. Only a fraction of
this time is "learning curve", it's mostly unexpected or missing behaviour.

 

The rest of my wasted is spent writing XAML by hand in the VS2010 lower
pane, then seeing if it looks vaguely acceptable above. The last time I
coded like this was in 1993 when I wrote HTML in Notepad. And no, Expression
Blend is a stinking pile of merde and using it would probably double my
development time (I'm a one person team).

 

However, I have some good news: The resulting app is starting to look much
snazzier and modern than a WinForms equivalent. However, a lot of this nice
look is thanks to the AvalonDock project and not specifically to WPF.

 

Greg

_______________________________________________
ozwpf mailing list
[email protected]
http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf

Reply via email to