BTW I love the CallMethodAction in Blend so I don't have to define Command in my ViewModels. It feels more POCOish. Just a public method. If I need the IsEnabled I just add a property and bind it to either IsEnabled or Visibility. <rant> Commands are just too messy and feels like leaking view concerns into my VMs. Just for the same reason I don't expose properties of type Visibility, I don't like exposing ICommand. Setting purity aside, it's just too much work, create another property that delegates on your method, initialise it in the constructor, then find ways to actually be able to call that from code... naaa. That's just messy. </rant>
On Sun, Nov 7, 2010 at 7:26 PM, Miguel Madero <[email protected]> wrote: > +1 for Blend Triggers and Actions > +1 for Code Behind for uncommon scenarios as a second option. > > On Tue, Nov 2, 2010 at 2:36 PM, Paul Stovell <[email protected]>wrote: > >> 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 >> >> >> >> _______________________________________________ >> >> ozwpf mailing list >> [email protected] >> http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf >> >> > > > -- > Miguel A. Madero Reyes > www.miguelmadero.com (blog) > [email protected] > -- Miguel A. Madero Reyes www.miguelmadero.com (blog) [email protected]
_______________________________________________ ozwpf mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
