ActionCatalogService: Question if action is run

Topics: CAB & Smart Client Software Factory
Jul 18, 2006 at 2:34 PM
originally posted by: kscott

Using the ActionCatalogService along with some ActionConditions.

Everything is wired up and working; I get the code in the condition triggered, and the action is called or not, as appropriate.

My question: How can I find out, in the original caller of the action, if the action was actually run or not.

My scenario is this: I want to use an action to notify modules that the shell application is being closed. I plan to have each module register an ActionCondition for the ApplicationClosing action.

If the app close is not allowed, I need to set the e.Cancel for the original (WinForms) FormClosing event, to keep the shell from shutting down.

Any suggestions?
Jul 18, 2006 at 6:09 PM
originally posted by: askew

Try the Event Broker.
Jul 19, 2006 at 11:23 AM
originally posted by: kscott

Meaning, use an event instead of an action? Because the event carries an EventArgs with it, and can be set by each subscriber?

Does a reference to the same EventArgs get passed to all the subscribers?
Jul 19, 2006 at 7:06 PM
originally posted by: askew

This is a thread where the use of a WindowWorkspace follows that of a Modal Dialog, where the user can't proceed without first completing. Perhaps this is a solution to what you are wanting to do? When a module or view refuses to let the app close, it is probably a good target for what Chris is doing in the link above.

An event based solution would likely be inefficient.
Jul 19, 2006 at 7:51 PM
originally posted by: askew

You could publish an event from the Shell and subscribe to it from the modules.

I modified the Generic Infrastructure.Interface.EventArgs<T> class for this test, adding a setter to the 'Data' property to make it editable as it is passed around between modules. I sent an "OnCloseQuery" event to the modules with 'Infrastructure.Interface.EventArgs<bool>(true)' as the value the modules can edit. One module edited this flag to false and when it came back to the caller in the Shell, it was usable.

Having an editable EventArgs<T> 'Data' property is a security hole that subscribers could exploit; changing the value is not always good practice. I'm guessing this is why there was no setter for the property to begin with. It might be wise to have a corollary class to EventArgs<T> such as EditableEventArgs<T> for this purpose.