Nice, that's interesting, never seen that one, I hate having to declare ICommand's it's such a hassle just to wire something up.
How do you pass args/params with CallMethodAction On Sun, Nov 7, 2010 at 8:34 PM, Miguel Madero <[email protected]> wrote: > 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 > >
_______________________________________________ ozwpf mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
