Context Menu

Topics: CAB & Smart Client Software Factory
May 3, 2006 at 8:58 AM
originally posted by: saregama


Are there any best practices/suggestions/ideas for implementing context menus within the CAB framework. I'm trying to come up with a generic context menu that is available to all controls and workspaces and have the capability to create additional specific menu items based on the controls itself.

Any suggestions/ideas would be greatly appreciated.
May 3, 2006 at 11:40 AM
originally posted by: ChrisHolmes

"generic context menu"

I'm confused by the contradiction. The whole idea behind a contextmenustrip is that it has a context and is thus not generic.

What problem are you trying to solve?
May 3, 2006 at 8:42 PM
originally posted by: atome

I need something similar in my application...

We can imagine a context menu which has 3 items "Add" "Edit" "Delete". This context menu could be shown in different places (treeview, lists, grids) even if those controls don't display the same kind of data (mails, contacts, tasks, etc.). Then, according to the 'context', we can add some specifics items : "Reply" for a mail, "Send email" for a contact, "Set as finished" for a task etc.

If you look at outlook 2003, there is a context menu which has some shared items : "Open", "Print", "Forward", etc.

I think that is what saregama is talking about.
May 4, 2006 at 6:35 AM
originally posted by: saregama

Yes, this is the exact problem that I'm trying to solve
May 4, 2006 at 6:58 AM
originally posted by: ChrisHolmes

This is an interesting thread. It's making me think differently about menu and toolstrip functionality in CAB.

So, it sounds to me like what you want is a ContextMenuStrip that has the proper CAB support so it works like a ToolStrip or MenuStrip. You can do that - you'd have to create a custom control and implement a UIAdapter, UIAdapterFactory and ItemCommandAdapter and that should give you a CAB usable ContextMenuStrip. But I'm still not sure it would solve the problem.

My main questions is, if you click on the general "Add" button how does it know which WorkItem to manipulate? How does it know which List to add to?

For instance, as a test scenario, assume you wanted this same generic functionality through the regular ToolStrip (use the ToolStrip as a proxy to the ContextMenuStrip, it's the same idea). You place a generic "Add" button the Toolstrip in the Shell. Thus, every WorkItem that shows in the shell has the "Add" button on the ToolStrip. Common, generic functionality. But how do you properly wire up Commands so that when WorkItemA is showing and "Add" is pressed it adds an item to WorkItemA, and when WorkItemB is showing and "Add" is pressed it adds an item to WorkItemB? How does that happen?

What I've been doing with my ToolStrip (and maybe there's a better way) is every WorkItem Clears() the ToolStrip when it gets shown in the Shell's DeckWorkspace. It then adds it's own buttons to the Toolstrip and wires up its own CommandHandlers. When a different workItem needs to be shown it Clears() as well and loads it's own buttons and Commands. This way they all share the same blank slate, but they all have their own CommandHandlers. Now, some of these buttons are pretty common across WorkItems, and some are not. I can see the desire to have have "Add" button the Toolstrip, so every WorkItem isn't creating their own version (consistency), but I can't see how the CommandHandling would work.
May 4, 2006 at 4:44 PM
originally posted by: saregama

Yes, you are right. I tried a few approaches today but could not get to wire the commandhandlers into the appropriate workitems.