For this I usually have a CanExecute property (which you usually have any way for Delegate or RelayCommands). That way the UI binds the IsEnable to the CanSave property. Seems like an extra step in Xaml, but that's one step less in the VM, plus it keeps it clean as well. I don't like invalidating commands when all I want to say is CanSave=true. I know there're implementations or RelayCommand that will Invalidate the command on property changed.
Also this works fine for buttons and cases where you want to disable something, but what if you want to make it invisible instead? You use a different type of CommandBinder and then things start to get messy when you could simple bind Visibility to the same CanSave property. On Tue, Nov 9, 2010 at 4:15 PM, <[email protected]> wrote: > I agree. MVVM is a pattern, and patterns can be implemented in any > number of ways. > > > > That said, ICommand is extremely useful if you drive it’s CanExecute in > your ViewModel. I mostly use ICommand (via a delegate command) on buttons > and menus which allows me to automatically disable these elements from data > driven events on the ViewModel without the ViewModel knowing anything about > the UI. > > > > Carl. > > > > *From:* [email protected] [mailto:[email protected]] > *On Behalf Of *Miguel Madero <[email protected]> > *Sent:* Tuesday, 9 November 2010 1:36 PM > > *To:* ozWPF <[email protected]> > *Subject:* Re: Events to command binding > > > > I personally don't think using a command would make it more or less MVVM. I > don't think commands are adding any value. Some would say they make it > explicit that something is a UI Command, for me a public method is just as > explicit. In terms of testability and separation of concerns, I think a > command actually does just the opposite than helping. In terms of line of > code (a metric we probably shouldn't be concern about anyway), it's pretty > much the same, although IMO the Codebehind approach is clearer. > > > > The only part where I would probably agree with the purists is that we run > the risk to accidentally end up with too much logic in the UI. > > > > On Tue, Nov 9, 2010 at 2:34 PM, Winston Pang <[email protected]> > wrote: > > Sometimes I am tempted to write code like that, but I'm afraid some MVVM > purist or some pedantic bastard will give me a purist talk. > > > > On Tue, Nov 9, 2010 at 2:33 PM, Miguel Madero <[email protected]> > wrote: > > >From codebehind yes. > > > > Let's assume you have a button in your listBox's datatemplate. > > > > public OnDeleteButtonClick(o...e..){ > > var orderToDelete = ((Button)o).DataContext; > > var viewModel = (MyViewModel)DataContext; > > viewModel.DeleteOrder(orderToDelete); > > } > > > > I tend to have a property that gives me the ViewModel just to remove the > cast from my code. > > > > On Tue, Nov 9, 2010 at 8:47 AM, Winston Pang <[email protected]> > wrote: > > Oh right, as in, casting DataContext to the respective VM and invoking it > with respective params? > > > > On Tue, Nov 9, 2010 at 9:42 AM, Miguel Madero <[email protected]> wrote: > > 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 > > > > > _______________________________________________ > 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 > > > > > _______________________________________________ > ozwpf mailing list > [email protected] > http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf > > > > > -- > Miguel A. Madero Reyes > www.miguelmadero.com (blog) > [email protected] > > > ______________________________________________________________________ > 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 > > -- Miguel A. Madero Reyes www.miguelmadero.com (blog) [email protected]
_______________________________________________ ozwpf mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
