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.