Combined context menus in a CAB application

As with my previous post on context menus in CAB applications, this post may well only really apply to the following scenario.

The application is a composite style application using the Microsoft Composite Application Block (CAB) libraries. There are several independent couples that can be included/excluded without affecting the other modules. There is a common Domain Model that represents the pure business domain of the application; each module largely just acts as a UI/View for an aspect of the model. The Shell of the application makes use of the Infragistics ToolbarManager (Office 2007 ribbon style).

The next problem I encountered was that although a domain entity should have a common context menu for all modules, some additional options should only be available from some of the modules; for example one module supported multiple selection of the entity whereas another didn’t, therefore the ‘Filter on selected’ command only really made sense in one place.

After some thought I decided that the reason for the differences in the context menu options is that in each place there is a slightly different context; There is the context of the selected domain entity, along with the context of the control that was clicked on. Therefore I decided to split the context menu into different sections (each section would have its own heading label to indicate the context that the tools relate to), then when a right click is detected the module could make a call to the ContextMenuService to show a combined context menu, passing in the keys of all the context menu sections to show.

Previously with the ‘domain entity context menus’ the definition of the tools would live in the domain model; with the new local context menus the definition for the tools would reside in the module, clearly indicating that this context menu is not common, and relates chiefly to the module.

A problem I encountered with this approach is that the Infragistics toolbar manager does not have a built in method for showing multiple PopupMenuTools as a single context menu. Therefore my solution was that when a call was made to show a combined context menu a key would be created using the combination of all the context menus to be shown. A check would then be made to see if this specific combined context menu had already been created, if not, a new PopupMenuTool would be created, simply taking the tools from all the individual menus and adding them, in order, to the new menu.

This solution has worked remarkably well. There is an outstanding issue, in that if a tool is later added to one of the individual context menus it will not be picked up by any combined context menus already created; If this functionality was ever required it would be relatively simple to just catch when a tool was added to a context menu and make sure it was added to all the others at the same time; In my current application the context menus are defined at startup and never changed, so this problem never occurs.

Context menus in a CAB application

Recently I’ve been implementing right-click context menus in our application. The problems I encountered and the solution I reached may not be applicable to all CAB applications so I’ll give you the context (apologies for the bad joke!)

The application is a composite style application using the Microsoft Composite Application Block (CAB) libraries. There are several independent couples that can be included/excluded without affecting the other modules. There is a common Domain Model that represents the pure business domain of the application; each module largely just acts as a UI/View for an aspect of the model. The Shell of the application makes use of the Infragistics ToolbarManager (Office 2007 ribbon style).

The requirements I was trying to implement stated that if a representation of an entity in the domain model was right clicked on in any of the modules a context menu should be shown showing several commands that can be chosen for that entity. The commands in the context menu may act on one or more modules.

Problem 1 – Where should the code live?

The first problem I encountered was where should the context menus be created? If created in one/all of the modules then how do we maintain inter-module independence? We could end up with the same context menu duplicated in several of the modules. We could end up with a context menu that contains commands that act on a module that hasn’t been included. We could end up with modules communicating with each other (through some sort of interface to register commands with each other’s context menus – like UIExtensionSites in CAB).

So if not in a module then perhaps in the shell? This has the problem that the shell is generic and not tied to the domain (we even use the same shell in another application); it would be undesirable for the shell to be dependent upon domain model concepts.

This leaves the domain model as a possibiltiy, however, as we don’t want UI concerns in the domain model (like context menus). We need to create a part of the domain model that is about UI, it will act pretty much like it’s own module but will be a dependency for all/many of the modules (I believe the Smart Client Software Factory calls these Foundation Modules).

Problem 2 – What are the responsibility boundaries and the interfaces?

I decided that as much of the definition of the context menu should be in a ContextMenuService in the new domain.UI project. This class would define all the tools on the menu and interact with the shell to add them (The ToolbarManager needs the tools to be registered as root tools in the shell). Any tool that acted on a module (or many modules), would start off invisible; When the module is loaded it will communicate with the ContextMenuService and specify the tool keys that it will respond to, the first module to specify a tool will make the tool visible in the context menu (subsequent modules will have no effect).

Each module will handle the right-click event and tell the ContextMenuService to show the context menu for the clicked on instance of the domain entity. (This will also ’set the context’ for the menu modifying menu options based on the instance). Finally the ContextMenuService will call through to the Shell to instruct it to show the context menu at the current mouse location.