This is a fair question, and one that is a common, yet "solved" (debatably) problem within the MVVM architecture realm. If you are using an MVVM framework, you are likely to find something similar to the EventToCommand Behavior, here is the sample from the MVVM Light Toolkit.
In short, this allows you to map an event to a command binding like so:
<Rectangle Fill="White"
Stroke="Black"
Width="200"
Height="100">
<i:Interaction.Triggers>
<i:EventTrigger EventName="MouseEnter">
<cmd:EventToCommand Command="{Binding TestCommand,
Mode=OneWay}"
CommandParameter="{Binding Text,
ElementName=MyTextBox,
Mode=OneWay}"
MustToggleIsEnabledValue="True" />
</i:EventTrigger>
</i:Interaction.Triggers>
</Rectangle>
Update:
There are two other "reasonable" solutions to this problem:
One uses the now considered legacy "AttachedCommandBehavior" extension found here.
The other is a little bit irritating, but workable.
- Capture a command via en
event purely in the view.
- Query the control's DataSource Step
- Grab a string binding target
identifier that denotes your command
(perhaps using a const string on the
view)
- Invoke your command on
the view model via reflection and
pass in the command arguments.
This looks gross but I'm fairly certain is actually a bit faster than just using traditional command
bindings. In order to be sure I'd need to see the IL, and I don't think that it matters in this case.
/Update
I want to note however that this is not always an ideal situation. I've discovered that more often than not, I'm using EventToCommand to cover a design issue. Please consider the following:
- Use events and code behind to handle User-Interface related behaviors.
- Consider creating custom controls that have command bindings if appropriate, especially if you find yourself using commands to encapsulate event driven bevahior to set bound data that is then reflected in the view. (i.e. setting a transparency value based on proximity to a control or something similar)
- EventToCommand should most likely be used to handle "Command-like" events only (double clicking etc) not reactive events (mouse-over). However there is nothing preventing this. Implement as you see fit.
Most importantly perhaps is that you remember that you are the developer. Guidelines in themselves do not solve problems, but consideration of guidelines may make the solution to a problem apparent.