I don't see that exposing methods/functions on a ViewModel is against
MVVM; the behaviour is still defined on the view model and ready for an
external driver (such as UI or another data driven object).
As to the "not doing it right" comment, I was referring to trying to use
a command to hide an event. I understand the thought process to get to
that point, but at some stage in the "hours of time" trying to get
things to work you need to run the "am I doing this right" sanity check
and try and think of alternative solutions to the problem.
This is not a criticism or flame but it's a thinking pattern I see again
and again with people who have almost completed the journey from
thinking WinForms to thinking WPF.
You're spot on for building a good example. Once you've developed some
good techniques for solving some typical WPF problems you're a long way
to being an efficient WPF developer. With such a variety of ways to
solve problems in WPF you need to have a good library of code to lean on
when you have those "I've solved this problem before" moments.
Carl.
From: [email protected] [mailto:[email protected]]
On Behalf Of Greg Keogh <[email protected]>
Sent: Tuesday, 2 November 2010 2:06 PM
To: "'ozWPF'" <[email protected]>
Subject: RE: Events to command binding
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
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
_______________________________________________
ozwpf mailing list
[email protected]
http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
________________________________________________________________________
_______
This email has been scanned by the Bankwest Email Security System.
________________________________________________________________________
_______
_______________________________________________________________________________
Unencrypted electronic mail is not secure and may not be authentic.
If you have any doubts as to the contents please telephone to confirm.
This electronic transmission including any attachments is intended only
for those to whom it is addressed. It may contain copyright material or
information that is confidential, privileged or exempt from disclosure by law.
Any claim to privilege is not waived or lost by reason of mistaken transmission
of this information. If you are not the intended recipient you must not
distribute or copy this transmission and should please notify the sender.
Your costs for doing this will be reimbursed by the sender.
We do not accept liability in connection with computer virus, data corruption,
delay, interruption, unauthorised access or unauthorised amendment.
_______________________________________________________________________________
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
_______________________________________________
ozwpf mailing list
[email protected]
http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
