Before delving into a point-by-point explanation of how to resolve problems with docking views, lets consider the architecture.

The focal point of the docking views architecture is the SECDockableFrame class. This class is a hybrid of control bar and frame window. It possesses the attributes and functionality of both. Like a frame window, an instance of SECDockableFrame can parent a CView, CSplitterWnd, SECTabWnd or any CWnd-derivative. An SECDockableFrame also has an optional title bar for showing activation and contains the logic required to change the menu bar when activated, like a frame window. Like an SECControlBar, SECDockableFrame is resizable when it is docked.

The SECDockableFrame class is not the only component comprising the dockable views architecture. The SECMultiDocTemplate class plays a key role as well. SECMultiDocTemplate is derived from CMultiDocTemplate, whose role is to create the document, view, and frame window and then connect them. As you would expect, the SECMultiDocTemplate inherits most of its functionality from its base class. However, it adds knowledge of the SECDockableFrame class and knows how to open a new document as either a normal MDI child or as a docking document. In addition, the SECMutliDocTemplate class also adds a ToggleDocking member function that allows open documents to be toggled between docked and undocked states.

There are also changes and additions to existing classes such as SECMDIFrameWnd and SECMDIChildWnd. These changes ensure that SECDockableFrame objects are included in the command routing class chain so menu picks are properly routed to a docked document if it is active.