Multiple conventions per element type

Aug 30, 2010 at 11:13 PM

Right now it seems that the ConventionManager only supports one convention per element type, since it is a dictionary.

Is this by design? Because I have added a convention based on an InputGestureTrigger to MenuItem, so it will automatically create a trigger based on the InputGestureText I have specified in the XAML. However, this overwrites the existing 'Click' event convention.

Aug 31, 2010 at 1:32 PM

It is by design and has a specific usage within the framework. For your case, I would look at extending ConventionManager.AddCustomBindingBehavior That is probably the best place to handle this. I'm considering some improvements to the way this extensibility point works. So, if you make a fix, be on the lookout for a change in this in the next couple of weeks.

Aug 31, 2010 at 1:33 PM

Though, I could be confused about what it is you are trying to do exactly. Can you provide some more info and maybe some sample code?

Aug 31, 2010 at 2:55 PM

I was trying to add a convention whereby the InputGestureText of a MenuItem can also be used to trigger its attached message.

So this:

<MenuItem Header="E_xit" InputGestureText="Alt+X" cal:Message.Attach="Exit" />

Would have the effect that pressing Alt+X will call Exit (if CanExit is true). The trigger is attached to the root visual so that it becomes global.

My very hacky implementation of the trigger can be found here:

I was also thinking about just porting the VM-based menus from Caliburn Shell Framework, though, but I just wanted to understand the reasoning behind the 'one convention per type' limit.

Sep 1, 2010 at 3:31 AM

There are a lot of technical reasons why we are constrained to one ElementConvention per type. I don't want to go into all that here. But, now that I understand your scenario, I am positive it can be implemented by extending ConventionManager.AddCustomBindingBehavior

Sep 1, 2010 at 8:22 AM

Excellent, thanks!

Sep 1, 2010 at 3:16 PM

Actually, after thinking about it, that may not be the best place to plugin. I wasn't thinking clearly. You should probably look at customizing the ViewModelBinder.BindActions method. That's closer to what you want to do. Just study the original implementation a bit and I'm sure you can figure out how to add your custom scenario in.

Sep 16, 2010 at 7:08 PM

Although I initially implemented this, I have now taken another approach:

I simply ported the MenuModel and InputManager stuff from Caliburn.ShellFramework and that does the job quite nicely as well.