Feature request: More Granular Control over ActionMessage guard abilities

[andrewalex]

Background

The use of doublemouseclick on a listboxitem, is often tied to an "OK" button. In the current environment it's not feasible to bind them both to the same Method, with a Guard method (CanOk) requiring a selected item. The Guard is also applied to the doubleclick, which causes the item to disable, preventing it from ever being selectable.

Request

There are simple work arounds for this, but it does show some limitations within C.M.

Events like DoubleMouseClick should generally not change IsEnabled on a CanMethod, but would probably make sense to check on actual execution of the event.

Ideas

I see no way for an ActionMessage to know the type of event that will trigger it, making it easy to solve this in the provided Func/Actions.

Idea 1

the simplest solution and less unintrusive method is to allow ActionMessage to be subclassed.

• ActionMessage.Invoke is already virtual
• Parser.InterpretMessageText can be replaced already.
• Making either UpdateCoreAvailability or UpdateContext virtual would allow the needed changes
  • UpdateCoreAvailability could just be skipped
  • UpdateContext could create a customcontext caught by UpdateCoreAvailability

Idea 2

A nicer alternative (tho more intrusive to the codebase) is to use a DepProp to set the style of guard (course then parser needs to be figured out)

[nigel-sampson]

Can certainly see where you're coming from, I'd certainly like to stay away from ActionMessage having any knowledge of the trigger which enables custom triggers and a broader range of functionality.

I think virtualising UpdateContext would most likely be the least impactful solution and open up some more customisation opportunities.

[andrewalex]

Excellent. Thank you.

[andrewalex]

As a Followup I am now able to do the following on triggers in a UserControl

<caliburnhelpers.WindowKeyTrigger Key="F11">
  <caliburnhelpers:ActionMessageEx MethodName="DoDebug" GuardOnInvokeOnly="True" />
</caliburnhelpers.WindowKeyTrigger>

And the CanDoDebug does not end up disabling the entire UserControl

[nigel-sampson]

Glad to hear it.