By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,263 Members | 2,640 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,263 IT Pros & Developers. It's quick & easy.

Adding menu items to a control's context menu

P: n/a
MCM
I'm working on a plotting control. The plotting control will have a context
menu with basic commands for "scaling", "zooming", etc. Is there a way
that, from the parent form, I can add more commands to the control's context
menu?

I'm envisioning a case where the control has a set of context menu items,
and the parent form also has a set of context menu items.

Thanks.
Mar 7 '07 #1
Share this Question
Share on Google+
2 Replies


P: n/a
The ContextMenu class has a Popup event. In other words, just before the
ContextMenu is about to appear, the Popup event fires. The good thing about
this event is that it permits you to construct your ContextMenu *items*
on-the-fly. This means you can construct them or change their attributes
(ticked, disabled) etc. This on-demand behaviour is *much* better than
trying to keep a static menu "up to date", especially if items are being
ticked or disabled. For example, we might disable a "Delete" option if the
user has no permission to delete a row of data in a list.

By using the event to trigger the construction of the menu, you can receive
notification when the menu is required, and then construct it appropriately
based on currently known state. In your case that means combining your
control's context menu items with those of its parent, or of the form.

The object that receives the event needs to be in a position to grab the
menu items from both the control, and the form (and anything else), in order
to build a menu. We get around this by having a sub-classed "form" and a
sub-classed "control" that each possess the correct interfaces for talking
to one another.

A simpler method might be to have two handlers for the Popup event - one
pointing to the control and one pointing to the form. Each then contributes
their own items to the context menu. The only problem is that neither event
handler is "in control" - which makes it harder to code in my opinion.

In our particular implementation, we use the interface technique because we
want each component (form, control) to contribute its menu items, but we
want the ability for them to "blend together" if necessary. For example,
menu item #1 might be the form's, #2 is the control's, #3 is the form's etc.
Each component contributing menu items defines a "rank" for each of their
items, and the combination of all ranks determines the final sequence.
Separators can also be injected into the menu, again based on rank. Plus we
have additional logic to ensure that a separator is never at the beginning
or end of the context menu, there are never two separators adjacent to one
another, etc. By having one thing "in control" of the construction of the
context menu, we have reasonable decoupling without either component
worrying how they might "affect" the other (practically speaking, ranks
still need to be chosen pragmatically to ensure the menu sequence comes out
as intended).

Hope this helps.

Kevin

"MCM" <mc*******@digitalmetrology.comwrote in message
news:u1*************@TK2MSFTNGP04.phx.gbl...
I'm working on a plotting control. The plotting control will have a
context menu with basic commands for "scaling", "zooming", etc. Is there
a way that, from the parent form, I can add more commands to the control's
context menu?

I'm envisioning a case where the control has a set of context menu items,
and the parent form also has a set of context menu items.

Thanks.


Mar 7 '07 #2

P: n/a
MCM
Wow. Thanks Kevin,

You are doing exactly what I want to be doing. :) However, I'm going to
have to sort through this a bit more - you a slightly over my head in terms
of my C# abilities. Nonetheless, you've given me some very good advice,
I'll just have to do some Googling to come up with the code to support your
recommendation.

Thanks,

- Mark
"Kevin Frey" <ke**********@hotmail.comwrote in message
news:Og**************@TK2MSFTNGP04.phx.gbl...
The ContextMenu class has a Popup event. In other words, just before the
ContextMenu is about to appear, the Popup event fires. The good thing
about this event is that it permits you to construct your ContextMenu
*items* on-the-fly. This means you can construct them or change their
attributes (ticked, disabled) etc. This on-demand behaviour is *much*
better than trying to keep a static menu "up to date", especially if items
are being ticked or disabled. For example, we might disable a "Delete"
option if the user has no permission to delete a row of data in a list.

By using the event to trigger the construction of the menu, you can
receive notification when the menu is required, and then construct it
appropriately based on currently known state. In your case that means
combining your control's context menu items with those of its parent, or
of the form.

The object that receives the event needs to be in a position to grab the
menu items from both the control, and the form (and anything else), in
order to build a menu. We get around this by having a sub-classed "form"
and a sub-classed "control" that each possess the correct interfaces for
talking to one another.

A simpler method might be to have two handlers for the Popup event - one
pointing to the control and one pointing to the form. Each then
contributes their own items to the context menu. The only problem is that
neither event handler is "in control" - which makes it harder to code in
my opinion.

In our particular implementation, we use the interface technique because
we want each component (form, control) to contribute its menu items, but
we want the ability for them to "blend together" if necessary. For
example, menu item #1 might be the form's, #2 is the control's, #3 is the
form's etc. Each component contributing menu items defines a "rank" for
each of their items, and the combination of all ranks determines the final
sequence. Separators can also be injected into the menu, again based on
rank. Plus we have additional logic to ensure that a separator is never at
the beginning or end of the context menu, there are never two separators
adjacent to one another, etc. By having one thing "in control" of the
construction of the context menu, we have reasonable decoupling without
either component worrying how they might "affect" the other (practically
speaking, ranks still need to be chosen pragmatically to ensure the menu
sequence comes out as intended).

Hope this helps.

Kevin

"MCM" <mc*******@digitalmetrology.comwrote in message
news:u1*************@TK2MSFTNGP04.phx.gbl...
>I'm working on a plotting control. The plotting control will have a
context menu with basic commands for "scaling", "zooming", etc. Is there
a way that, from the parent form, I can add more commands to the
control's context menu?

I'm envisioning a case where the control has a set of context menu items,
and the parent form also has a set of context menu items.

Thanks.



Mar 8 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.