With the release of Windows 95, Microsoft made it known in The Windows Interface Guidelines for Software Design that they are moving away from MDI in their Office products; however Microsoft has not provided Windows operating-system-level support or MFC support for any of the MDI alternatives described in their design guide. Currently, MFC only supports the Multiple Document Interface (MDI) and Single-Document Interface (SDI), which are waning in popularity. Objective Toolkit proves you with three additional alternatives: MTI, FDI, and WDI.

MTI is a combination of SDI and MDI. As in SDI, each top-level window manipulates one document. As in MDI, the user can have multiple documents open simultaneously. MTI creates a new top-level window for each new document. MTI departs from the MDI model in which one parent frame owns and contains every document window.

From the user’s standpoint, an MTI application most closely resembles an SDI application because he can only associate one document with a frame.

However, note that when the user loads or creates document, an additional frame is created to hold the document instead of loading the document into the existing frame.

MTI-based applications create document windows that float freely on the desktop. This approach is common in other GUI operating systems such as the OSF/Motif windowing system for UNIX. It has also become a popular Windows interface. For example, you can easily activate MTI windows from the Windows 98 taskbar.

The SECToplevelFrame class is the basis for the MTI MDI-alternative. MTI applications derive from SECToplevelFrame whereas an MDI application would derive from CMDIChildWnd.

The following figure is the hierarchy for SECToplevelFrame.

The following sections describe how to create an MTI application from a new or existing MFC project.

The following sections show you how to modify the default behavior of an MTI application and present some information about message handling.

By default, MTI-based applications behave the same way as MDI apps. For example, when you open a MTI application one top-level frame window containing an empty, untitled document appears. If you select Open from the File menu and select a file, a new top-level window is created, and the document is displayed therein. When you open a file, you are actually opening two windows. One window is empty whereas the other window contains the document of interest. This is exactly the same behavior MDI applications exhibit. In some applications, it is preferable to load the document into the initial empty frame rather than create a new one.

There are a couple of key MTI data members that you need to consider if you’re setting up message dispatching for your MTI application:

The SECToplevelFrame class can act as more than a MDI alternative in your application. Because SECToplevelFrame is only varies slightly from CFrameWnd, you can use it anywhere you would have used CFrameWnd as a base class. SECToplevelFrame contains nothing that binds it to the document/view architecture, so you can use it in applications that do not adhere to doc/view architecture. When you use this class as a specialized frame window instead of an MDI alternative, SECToplevelFrame gives you the capability to create a top-level frame with any arbitrary client. The top-level frame is given its own entry in the Windows 98 task bar, and it can remain open when other application windows are iconified.

The Objective Toolkit mt_scrib sample (<stingray-installdir>\Samples\Toolkit\MFC\MDI\MTScribble) shows how to convert the MFC tutorial, Scribble, from MDI to MTI.

FDI is like MDI except in FDI the MDI children can float freely on the desktop. In MDI, the MDI children are confined to the MDI parent window. As with MDI, you can have multiple open documents in FDI. FDI creates a new floating child window for each new document. Each FDI child window appears as a top-level window and manipulates one document. Optionally, each FDI child window can include a menu bar containing menu items specific to that window.

As for the main window, all menu items need to apply at the application level or to all FDI children; otherwise, focus becomes an issue. For example, if you activate an FDI child and then pick a menu item from the main application window, the FDI child loses activation and consequently its menu pick. FDI-based applications have a look-and-feel that is similar to Microsoft Visual Basic.

Because FDI allows you to place document windows on the desktop, its interface is somewhat similar to MTI. In MTI, no main window owns all the other windows in the application. However, the concept of a main frame window remains to serve as a menu strip or primary application window. Because MTI document windows are root-level windows, they are given their own Windows 98 task bar entries. FDI document windows are not root-level windows. You can iconify MTI document windows independently of all other windows. In FDI, when the main application window is iconified, all the FDI children are iconified as well.

FDI is implemented in two classes that both derive from SECFrameWnd. This hierarchy is as follows.

The SECFDIChildWnd class is a document window that is similar to a MDI child window, except it can float freely on the desktop whereas a MDI child window is tied to its parent frame. FDI applications derive from SECFDIChildWnd. MDI applications derive from CMDIChildWnd.

The SECFDIFrameWnd class is a main frame window that adds support for the Window menu and the Windows… dialog. FDI applications derive from SECFDIFrameWnd. MDI application would derive from CMDIFrameWnd.

The following sections tell how to use FDI in new and existing projects.

The Objective Toolkit fdi sample (<stingray-installdir>\Samples\Toolkit\MFC\MDI\FDI) illustrates the use of the SECFDIChildWnd and SECFDIFrameWnd classes.

The WDI classes enhance MDI by allowing the user to place every document in a tabbed window. This reduces MDI modality. All of the documents are part of a workbook of worksheets. The user can open a specific worksheet by clicking a tab instead of selecting the Window menu and searching for it.

Because WDI adds an optional Workbook View to MDI, there is no cost associated with converting your MDI application to WDI. WDI enhances your MDI application without losing any functionality or fundamentally changing the MDI user interface. In other words, a WDI application with workbook viewing mode deactivated is equivalent to MDI.

New ‘flat’ style drawing has been added to the workbook window. In order to enable flat style drawing, you need to call the SetFlatStyleMode function (a member of the SECWorkbook class).

To view sample code which shows how to set the flat drawing style, please see the CMainFrame::OnCreate function implementation in MAINFRM.cpp, VIZ sample:

The Viz sample demonstrates this feature, and can be found at <stingray-installdir>\Samples\Toolkit\MFC\Docking\Viz.

New ‘flat’ style drawing has been added to the shortcut window. In order to enable flat style drawing, you need to call the SetFlatStyleFunction function (a member of the SECShortcutBar class).

To view sample code which shows how to set the flat drawing style, please see the CShortcutListDockBar::OnCreate function implementation in LSTDBAR.cpp, VIZ sample:

The Viz sample demonstrates this feature, and can be found at <stingray-installdir>\Samples\Toolkit\MFC\Docking\Viz.

New ‘flat’ style drawing has been added to the 3D tab control window. In order to enable flat style drawing, you need to set the TWS_FLATSTYLE window style while creating the tab control window. Alternatively, you can enable flat style drawing at a later time by calling the SetTabStyle function (a member of the SEC3DTabWnd class).

To view sample code which shows how to enable flat style drawing for tabbed control windows during creation time, please see the ProjectWorkspaceWnd::OnCreate function implementation in PRJBAR.cpp fo the Viz sample:

To view sample code which shows how to toggle flat style drawing for tabbed control windows, please see the CChildFrame2::OnSwitchFlat function implementation in CHLDFRM2.cpp of the TabDemo sample:

The TabDemo sample does not ship with the product. For information on where you can obtain this sample, see “Location of Sample Code” in the Getting Started part.

The Viz sample also demonstrates this feature. It can be found in at <stingray-installdir>\Samples\Toolkit\MFC\Docking\Viz directory.

WDI support is provided by a combination of three MFC extensions: SECWorkbookWnd, SECWorksheetWnd, and SECWorkbookClientWnd.

The SECWorkbookWnd class is derived from SECMDIFrameWnd. It adds the workbook interface (WDI) enhancements. Derive your main frame window class from SECWorkbookWnd if you want the workbook interface enhancements.

The SECWorksheetWnd class is derived from SECMDIChildWnd. It adds the workbook interface (WDI) enhancements. Derive your MDI child windows from SECWorksheetWnd if you want to implement the workbook interface enhancements.

The SECWorkbookClientWnd subclasses the MDI client window and is implemented as a part of the workbook interface. SECWorkbookClientWnd allows the WDI framework to hook into CFrameWnd’s window layout calculation and specify a client area that allots space for drawing the border and tabs.

SECWorkbookWnd has overridable functions that you can use to customize several aspects of WDI including:

Override the AddSheet() and RemoveSheet() member functions. These members are expected to assign values to SECWorksheetWnd::m_nPosition for every worksheet in your workbook. In your override, you can assign any tab position to newly created worksheets.

Override the SECWorkbookWnd::GetTabLabel() function.

Override the SECWorkbookWnd::GetTabIcon() function.

Override the SECWorkbookWnd::OnDrawTab() and SECWorkbookWnd::OnDrawTablconAndLabel() functions.

A summary of the key methods and data members that you can use to customize the WDI is presented in the table below.