What is the best way to access elements of parent control from a child control?

Question

I have a parent control (main form) and a child control (user control). The child control has some code, which determines what functions the application can perform (e.g. save files, write logs etc.). I need to show/hide, enable/disable main menu items of the main form according to the functionality. As I can't just write MainMenu.MenuItem1.Visible = false; (the main menu is not visible from the child control), I fire an event in the child control and handle this event on the main form. The problem is I need to pass what elements of the menu need to be shown/hidden. To do this I created an enum, showing what to do with the item

public enum ItemMode
{
    TRUE, FALSE, NONE
}

Then I created my eventargs which have 6 parameters of type ItemMode (there are 6 menu items I need to manage). So any time I need to show the 1st item, hide the 2nd and do nothing with the rest I have to write something like this

e = new ItemModeEventArgs(ItemMode.TRUE, ItemMode.FALSE, ItemMode.NONE, ItemMode.NONE, ItemMode.NONE, ItemMode.NONE);
FireMyEvent(e);

This seems like too much code to me and what's more, what if I need to manage 10 items in future? Then I will have to rewrite all the constructors just to add 4 more NONEs.

I believe there's a better way of doing this, but I just can't figure out what it is.

Answer 1

There truly are many ways this could be done. The easiest way, although some will shout "bad practice", would be to just pass a pointer to the main menu when the control is created. Your control would have some code like this:

MenuStrip MainMenu;

internal void SetMainMenu(MenuStrip mainMenu)
{
    MainMenu = mainMenu;
}

and when you create the control:

void CreateControl()
{
    MyUserControlType MyControl = new MyUserControlType();
    MyControl.SetMainMenu(mainMenuStrip); //or whatever you called your main menu
}

This will give your child form unlimited access to the mainform's menu (which is why it's technically a bad practice). From the child form you can access the submenus by name, eg:

if (MainMenu != null)
{
    ToolStripMenuItem fileMenu = 
        (ToolStripMenuItem)MainMenu.Items["fileToolStripMenuItem"];
    fileMenu.DropDownItems["exportFileToolStripItem"].Visible = false;
}

If you created the control in the designer, then you can add the SetMainMenu call into the .design file, or add it in the Form's load event.

Answer 2

If you want to handle all changes from the user control: you could inherit your own user control class and add a reference to the form/collection of menu entries you want to be able to modify. You would pass this reference to its constructor and then you'll be able to easily modify the menu from inside your user control

If, on the other hand, you would like to manage this on an event basis in your form, you could implement your own EventArgs class, but I would do it like this:

class ItemModeEventArgs
{
    MenuItemClass target;
    EnumType change;
}

So basically for each menu item a separate event is risen. Every event args knows about what item menu is changing and how it is changing. Ofc, if you only have two states for the menu items, the 'change' field is kinda useless. This way you don't have to hardcode functions with n parameters where n is the number of menu items.

Answer 3

Well, I can't speak to a "best" way unless except in specific cases, since there are often several equally good ways. My first thought, though, would be to create a class that has a property which the parent assigns a reference of its MainMenu, and which has functions for enabling/disabling individual menus or items. In a very simple case, this could be as simple as passing a list of strings like "OptionsScreen=enabled" etc. and then inside the class manually handling those cases, to something more generic like passing strings such as "mnuToolsOptions=enabled" and then finding the menu item via the .Name property. So, on startup, create an instance of your menu handler class, then do something like MenuHandlerHelper.MenuToHandle = MainMenuStrip;.

On the child side, you could perhaps have your classes that update the MainMenu be derived UserObjects that derive from a common one you create that has a public MyMainMenuHandlerHelper MenuHandlerHelper property, and set that in your Parent form's constructor so the Child controls could call the menu updating function. Or, you could have an event that just passed back a List<string> containing all the rules, and fire that as you are doing now.

This is a very simple idea, and doesn't handle things like possible collisions, so you would probably either want to throw an exception (easiest). You might also want to have rule priorities (easy), or try to chain functionality (could be hard to determine orders and such).

I would be happy to implement some examples of my thinking if you can constrain the problem a little for me (desired collision handling, etc.) and I actually wanted to see what some basic code would look like and try perhaps to test a couple of ideas, so if those come to anything I will post the code here for those as well.

Answer 4

The chain child->parent can be reversed. In such scenario requests will be passed from the mainform to its child controls.

Controls participating in the command processing must implement a special interface:

  interface ICommandHandler
  {
        bool CanInvoke(int commandId);
        void InvokeCommand(int commandId);
        bool UpdateCommand(int commandId, MenuItem item);
  }

The advantage of this approach is that only active controls must be traversed, not all the children. The weak point - UpdateCommand() method, which could be called from Application.Idle event or timer.

hope this helps

Answer 5

you could create an EventArgs which takes an ItemMode[] or a List<ItemMode> or a Dictionary<string, ItemMode> for those items (instead of the current 6 arguments) - that way you don't need to change much when adding more items...