Can someone please explain WHY you need a dummy child form instance for the BarManager?

[Steve Weixel]

I saw the earlier explanation (in response to a question about the constructor being called twice), and I don't buy it. You say that it is required so that you can display the disabled items when the form is not visible or active, but this doesn't make any sense because the dummy form isn't visible or active either. So I don't see what is gained by doing this other than causing random problems because of mysterious interactions with the form.

[Administrator]

Steve,

Let me try to explain the rationale behind this requirement. In XPMenus, 2 MDI merging modes are supported:

1) Explicit Merging (by calling RegisterMDIChildTypes):
In this mode, the toolbars of the child Forms are available to be shown all the time (even when the child Forms are not Visible). This behavior is like VS.Net where you can show the toolbars (albeit the items being disabled) associated with the "Designer" even when there is no Design Surface open.
This is possible only by creating a dummy child Form and querying for it's menus and toolbars.

2) Auto Merging:

In this mode, the toolbars of the child Forms are made visible as and when the child Forms are made Visible.

In this scenario, as you suggest, our framework could use the menu and toolbar information from the already loaded child Form (rather than creating a dummy child Form) to draw the menu/toolbar items. This is some thing we are currently investigating and planning to support in our next version.

Regards,
Praveen Ramesh