I agree. While it's a good guide to learners to eliminate code in the
code behind, it's not always the best practice. As long as you design
it so that the UI is able to be thrown away / easily replaced with
another UI on top of the same ViewModel you should be fine.
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.
And remember one of the golden rules; if it's taking too long you're
probably not doing it right.
Carl.
Carl Scarlett
Senior .NET/WPF Developer, UX Designer - Genesis Team
IT Applications Delivery | Bankwest
A: Level 5, 199 Hay Street | Perth | Western Australia | 6004
P: (08) 9449 8703
M: 0408 913 870
E: [email protected]
AFR Smart Investor Blue Ribbon Awards
2010 Bank of the Year
From: [email protected] [mailto:[email protected]]
On Behalf Of Paul Stovell <[email protected]>
Sent: Tuesday, 2 November 2010 12:36 PM
To: ozWPF <[email protected]>
Subject: RE: Events to command binding
There is an Expression Blend trigger action that can invoke a command
IIRC. That's probably the easiest way.
Caliburn also has a nice approach of mapping an event to a ViewModel
method via an attached property - something like <Button
cal:Message.Attach='[Event MouseOver] = DoSomething()' />
Personally, if there's no command out of the box and it's not a common
scenario, I'm quite happy to write a plain old event handler and invoke
the method on the VM manually. There's nothing wrong with a little code
behind.
Paul
From: [email protected] [mailto:[email protected]]
On Behalf Of Greg Keogh
Sent: Tuesday, 2 November 2010 2:31 PM
To: 'ozWPF'
Subject: Events to command binding
Some have scoffed when I expressed dismay at the artifice that creates
binding. I've just discovered that I'm wasting hours of time converting
events into commands. For example, iIt took me an hour to find a piece
of sample code that converted KeyDown on TreeView nodes to a binding
(found HERE
<http://stackoverflow.com/questions/612966/keyboard-events-in-a-wpf-mvvm
-application> ), but it needed delicate merging with existing ICommand
processing classes I use.
I estimate that 50% of the time I spend writing WPF apps is wasted
trying to follow MVVM and bind the control XAML to my controller class.
It seems that every other man and his dog who is trying to follow the
MVVM pattern as well has created untold amounts of confusing and
conflicting code for the purpose. I'm sick of searching for and finding
jumbles of code that I have to tidy up and include in my projects.
I feel compelled to write a small infrastructure that allows
event-to-command binding in a generalised way, but I'll bet it's been
done already (multiple times and in multiple ways). Has anyone got any
suggestions or comments on this? Surely I'm not the first person in the
world to have stumbled across these hurdles.
MVVM would be wonderful if all of the wiring was just built-in.
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
