I rarely have to pass parameters. The CallMethodAction doesn't have this option. I prefer parameterless methods and databind to properties to give my VMs the extra context. In cases where this isn't possible I do it from code behind. I guess it would be really simple to write a CallMethodAction that takes a parameter or parameter list if you need this functionality. Since this isn't a common task for me, it has been simpler to write an event handler and directly call the method.
On Mon, Nov 8, 2010 at 7:45 PM, Winston Pang <[email protected]> wrote: > 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 > > -- Miguel A. Madero Reyes www.miguelmadero.com (blog) [email protected]
_______________________________________________ ozwpf mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
