### Creating a Frame Window

Use the IFrameWindow class to create a frame window. The default style of the IFrameWindow class has a title bar, system menu, minimize button, maximize button, and border. The default style adds an entry for the frame window to the system window list.

In Motif, the default style of the IFrameWindow class has a title bar, window menu button, minimize button, maximize button, and resize window border. The window menu button on AIX is a system menu button on OS/2. The Open Class Class Library uses the IFrameWindow::systemMenu style to create the window menu button for AIX.

The IFrameWindow class also provides several other styles. You can, for example, associate an accelerator key table to the frame window or provide an icon to be used when the window is minimized.

When you construct an IFrameWindow with a style of IFrameWindow::minimizedIcon, IFrameWindow::accelerator, or IFrameWindow::menuBar, resources corresponding to the style must be in the resource library you use to construct the frame. This library is usually the default user library, which you can use by typing:

    IApplication::current().userResourceLibrary()

You can explicitly specify the resource library on the IFrameWindow constructor by using the const IResourceId argument, giving an IResourceLibrary value.

When you construct an IFrameWindow with a style of minimizedIcon, accelerator, or menuBar, the corresponding resource defined with the IFrameWindow window ID in the resource file is automatically loaded. If a required resource is not found, an exception is thrown, and the frame window is not constructed.

The following shows the components of a frame window created using the IFrameWindow class with the default style and some added controls.

The following example defines a frame window:

    //*****************************************************************************
    // framewin.cpp.                                                              *
    //*****************************************************************************
    #include <iframe.hpp> #include <iapp.hpp>
    //*****************************************************************************
    // Main Routine - application entry point                                     *
    //*****************************************************************************
    int main()
    {
        ICoordinateSystem::setApplicationOrientation(
                   ICoordinateSystem::originLowerLeft);

    //*********************************************************
    // Construct the frame window
    //*********************************************************
    IFrameWindow frame("Basic Frame Window",
                        WID_MAIN,
                        IFrameWindow::defaultStyle());
    frame.setFocus().show();

    //*********************************************************
    // Add event handling
    //*********************************************************
    IApplication::current().run();

    return 0;

    }

The following figure shows the frame window created using the preceding example:

When a frame window is minimized, the frame window hides and draws its minimized icon. Sometimes other windows associated with the frame window are drawn on top of its icon. This occurs when the windows are children of the frame window but not the client window or frame extensions.

To suppress the drawing of child windows that are not frame extensions or the client window when they are supposed to be minimized, add a handler to the frame window that detects when the frame is minimized, and hides these windows. The handler should make these windows visible when the frame is restored.

The Open Class Library defers positioning and sizing components of a frame window until the frame window shows. As a result, if you query the size and position of the frame window's client window or frame extensions, an accurate value is not returned until the frame window is shown.

The IWindow::show or IFrameWindow::showModally member functions automatically update the frame window.

You can force the frame window to update itself by calling the IFrameWindow::update member function.

#### Porting Applications with Frame Windows

The following limitations exist on the Windows platform with respect to child frame windows. A child frame window is one whose parent is not IWindow::desktopWindow.

- Focus will not be given to the child window and its title bar will appear as an inactive window.
- Minimizing to the parent window client area will not work. In particular, the icon may not be visible.
- Menus cannot be added to the child frame window.
- Child frame windows are not added to the task list or task bar.

We recommend that you do not use the following styles on child frame windows in portable applications:

  IFrameWindow::maximizeButton
  IFrameWindow::maximized
  IFrameWindow::menuBar
  IFrameWindow::minimizeButton
  IFrameWindow::minimized
  IFrameWindow::minimizedIcon
  IFrameWindow::shellPosition
  IFrameWindow::sizingBorder
  IFrameWindow::systemMenu
  IFrameWindow::systemModal
  IFrameWindow::titleBar
  IFrameWindow::windowList

An alternative to MDI style child windows which is more consistent with the PM, Motif, and 32-bit Windows style guides is to use secondary frame windows. You can create such windows with IBM Open Class Library by specifying the parent window as IWindow::desktopWindow() (or 0), and the primary frame as the owner.

Frame extensions are non-portable. Like the Windows operating system, control of the appearance of frame window decorations lies primarily with the system. Windows gives you a little more control (you can draw your own title bar, for example). Frame extensions in the non-client area are not supported in either environment. MDI is not supported on Motif and IOC does not support MDI correctly in Windows either. The main problem is attaching extensions to menus and title bar. You can not do this at all in Motif. Tool bar provides a better alternative for many of the cases where this is used.

There is a new version of IWindow::create that takes an IWindow* for parent and owner instead of IWindowHandles. Use this new create when you subclass an IWindow object. The library then ensures that the correct handle for the creation (parent->handleForChildCreation) of the control is used.

The use of handle on Motif was different than on Windows and OS/2. If an aggregate could have children, such as IFrameWindow and IViewPort, handle was used as the parent of the child. Windows and OS/2 get around this problem by using a setParent to change the parent of the child to the correct control. Motif can not use this technique because reparenting is not available. Motif had a topHandle and a handle so that children of a control can have a different parent handle than the handle used for geometry management. In Motif, the topHandle was the handle of the control (widget) that encompassed all of the widgets of the aggregate. The topHandle was used for geometry management of the control such as moving and sizing the control. The problem with topHandle is that is was motif only and had the same meaning as handle does on OS/2 and Windows.

A new member function returns the handle that a child of a control should use as their parent. When a control is created and an IWindow* is specified as the parent, we use handleForChildsParent instead of handle. The default implementation of handleForChildsParent just returns handle. Any subclass that needs a different implementation, like IViewPort, overrides this member function and returns the appropriate handle.

Windows

Changing the Title Bar
Creating an Information Area
Adding Styles
Using Cursor Classes
Creating a Message Box
Adding Menus to your Application
Adding a Menu Bar

IEvent
IFrameWindow
IHandler
IInfoArea
IMenu
ITitle