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
However, I'm going to