I agree. I was assuming the use of command when I mentioned we will bind that property, my point is, that the Command wouldn't help in that scenario.
On Tue, Nov 9, 2010 at 4:53 PM, <[email protected]> wrote: > In that situation I use a converter to convert the boolean (from the > CanExecute) into an appropriate visibility value. > > > > Converters rock. > > > > *From:* [email protected] [mailto:[email protected]] > *On Behalf Of *Miguel Madero <[email protected]> > *Sent:* Tuesday, 9 November 2010 2:46 PM > > *To:* ozWPF <[email protected]> > *Subject:* Re: Events to command binding > > > > 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] > > > ______________________________________________________________________ > 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
