>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
