Implementation of toolstrip Merging

Article 1: toolstrip Merging)

The approximate structure of this model is as follows:
One MDI main form, 1 ~ N mdi child forms;
There is usually one main menu bar on the main form, 1 ~ N main toolbar;
There may be 0 ~ 1 Main Menu Bar, 0 ~ One main toolbar. The menu bar and toolbar of the child form are displayed on the main form during running and merged with the menu bar and toolbar of the main form. (In fact, there may be multiple toolbar, but it is not difficult to merge multiple toolbar after the model is simplified to a toolbar and a toolbar is merged ).
For Menu Bar merging, both traditional Windows API programming and window forms have been perfectly solved.
It is best to enable and disable the process of merging the toolbar in the subform. One easy way to think of is to write the events in the subform. Code In, you must either write code similar to processing in the code file of each sub-form, or let all sub-forms inherit from a form that writes the relevant event processing code. The former is obviously not desirable. In the era of single inheritance, it is not a good way to deprive sub-forms of the possibility of inheriting from other forms. At the same time, a disadvantage is that the child form needs to access the content of the main form, and the coupling degree is too high.
The best solution also comes out naturally, that is, processing in the mdichildactivate event of the main form (we cannot expect that only the activation of the child form will trigger this event, in fact, the closure of sub-forms will also trigger this event ). In this case, the toolbar content of the main form merged from the previous subform should be cleared (if any ), merge the content of the toolbar to be merged on the newly activated child form to the toolbar of the main form (if there is no content of the toolbar to be merged on the newly activated child form or mdichildactivate is to close the last this step is not required when the sub-form is triggered ). To simplify the code, it is assumed that the toolbar of the child form is always merged to the last position of the toolbar of the main form.
At this time, the main form must know the composition of the toolbar of the child form. It is impossible to completely decouple the child form. One way is to set the scope of the Toolbar Control of the child form to public. I have adopted another method, that is, to define an interface, you can merge the subwindows In the toolbar to implement this interface.
The interface code is as follows: Using System;
Using System. Collections. Generic;
Using System. text;
Using System. Windows. forms;

NamespaceOsmanthus. winforms
{
InterfaceItoolstripmergableform
{

Toolstrip mergedtoolstrip
{
Get;
}
}
}

Let the subform implement this interface, and the code to be written is also simple, with only one sentence, namely: PublicToolstrip mergedtoolstrip
{
Get{Return This. Toolstrip1 ;}
}

The rest of the content seems ideal, of course, to write the mdichildactivate event processing code for the main form. However, to increase reusability, I write it as a component. In the future, I only need to drag and drop this component in the primary form of MDI, and set this component Maintoolstrip Attribute The toolbar for the main form (in fact, you can also write it to automatically obtain the default attribute value, that is, the last toolstrip control on the main form), without writing a line of code to the main form. The code for this part is as follows (for Component Access to form, refer to the masterpiece of Chris sells. I don't know if there are other better methods ): Using System;
Using System. Collections. Generic;
Using System. text;
Using System. Windows. forms;
Using System. componentmodel;
Using System. componentmodel. design;

Namespace Osmanthus. winforms
{
Class Sditoolstripmerger: component, isupportinitialize
{
Private Form hostingform;
Private Toolstrip maintoolstrip;
Private Itoolstripmergableform currentmdichild =   Null ;

PrivateList<Toolstripitem>Toolstripitemlist= NewList<Toolstripitem>();

PublicToolstrip maintoolstrip
{
Get{ReturnMaintoolstrip ;}
Set{Maintoolstrip=Value ;}
}

[Browsableattribute ( False )]
Public Form hostingform
{
Get
{
If (Hostingform =   Null ) &&   This . DesignMode)
{
Idesignerhost designer =   This . Getservice ( Typeof (Idesignerhost )) As Idesignerhost;
If (Designer ! =   Null )
{
Hostingform = Designer. rootcomponent As Form;
}
}
Return Hostingform;
}
Set
{
Hostingform = Value; // here we need to improve it. Once host form is set, it cannot be modified.
}
}

# RegionIsupportinitialize members

Public VoidBegininit ()
{
}

Public   Void Endinit ()
{
If (( ! DesignMode) && (Hostingform ! =   Null ))
{
Hostingform. mdichildactivate + =   New Eventhandler (updatemedilstrip );
};
}
# Endregion

Void Updatemedilstrip ( Object Sender, eventargs E)
{
// Clear the toolbar content merged from the previous activation subform
If (Currentmdichild ! =   Null )
{
Foreach (Toolstripitem toolitem In toolstripitemlist)
{< br> currentmdichild. mergedtoolstrip. items. add (toolitem);
}< br> toolstripitemlist. clear ();
}

itoolstripmergableform form = (itoolstripmergableform) hostingform. activemdichild;
// If the currently activated sub-form implements itoolstripmergableform interface, merge the toolbar content
If (Form ! = null )
{

Currentmdichild = Form;
Foreach (Toolstripitem toolitem In Currentmdichild. mergedtoolstrip. Items)
{
Toolstripitemlist. Add (toolitem );
}
Foreach (Toolstripitem toolitem In Toolstripitemlist)
{
Maintoolstrip. Items. Add (toolitem );
}
}
Else
{
Currentmdichild =   Null ;
Toolstripitemlist. Clear ();
}
}
}
}

Note: This morning I found the newly added. NET Framework 2.0OneToolstripmanager class, which can simplify the above Code.