… standard events like MouseDown, KeyUp.
P682 [[wpf recipes]] presented a surprisingly brief yet complete solution. The sample code takes fewer than 10 lines of xaml and c#,
but it's good to point out the salient features —
– no command, just routed events
– this technique requires a containment hierarchy, which exists in every WPF window
– If you want to suppress an event within a container, then apply the trick at that container level
– Trick is on the Preview tunneling event
–IV + proj
dprop (dependency property), aprop (attached property)?
logical ^ visual tree
containers – details
event handling – deeper
various common controls
bind to a method
templates – succinctly
resource dictionary? succinctly
observable collection? pro
alternatives to mvvm? pro
threading problems in wpf? pro
In most of my projects, my commands inevitably need access to the VM. The Execute() and CanExecute() all need to access the VM. (See
other posts why VM is one of the top 3 players in a command set-up.)
Q: how does the command methods get a handle on the VMs? I know more than 1 technique.
A: [[wpf succinctly]] shows that in xaml, we can pass the VM as CommandParameter into the Execute() method
A: ctor injection — VM is constructor-injected in the command instance.
In a way, the command objects and VM objects are inter-dependent.
0) The VM often exposes the command as a CLR property, to be accessed by the xaml “Hollywood”
1) The command methods directly uses the VM object.
To reduce coupling, perhaps we can introduce interfaces. Necessary?