Contents Up Previous Next

Windows

An application presents the user primarily with a series of windows. A window can be made up of a frame with one or more subwindows. This is like the XView model, rather than Motif or MS Windows where child windows may be nested to any depth. The frame/subwindow method was chosen since XView required it, and because it is a useful simplifying assumption, imposing few restrictions in practise. However, from version 1.61, wxWindows relaxes some of these restrictions for platforms that allow it. Text windows and canvases may be placed on a panel under Windows and Motif, and under Windows, Motif and XView wxPanel is a subclass of wxCanvas, inheriting most of its properties including the ability to draw to a device context. Work is underway to simulate subwindow nesting under XView.

Note that the splitting of canvas views (as in the Open Look standard and some other platforms) is not allowed in wxWindows. It is envisaged that this will be eventually be introduced into wxWindows.

A frame window may be parentless or a child of another frame, and may be iconized. It may have a menu bar, a row of pull-down menus along the top of the frame. Subwindows within a frame come in three varieties: the panel, canvas and text subwindow. A panel is used for buttons, lists and other such user input items, while a canvas is used for drawing graphics such as lines and shapes. Panel items pass high-level notification of user interaction to the program, whereas any interaction with objects on a canvas must be programmed at a lower level.

In MS Windows, canvases need to be painted using a handle to a 'device context'. The purpose of this is to enable the same code to draw into a number of different devices, such as printers, windows, bitmaps and metafiles. wxWindows also has the notion of a device context, but most drawing commands may also be directly issued to a canvas for convenience. An application which implements a function to draw into the base device context, wxDC will be able to pass any device context object to this drawing function, including wxPostScriptDC, wxCanvasDC, wxMetaFileDC, and wxMemoryDC.

wxWindows defines several objects required for drawing on canvases: colours, fonts, pens and brushes. Neither XView nor Motif provides pens and brushes, which in MS Windows allow the selection of different predefined 'drawing tools' with certain characteristics (line thickness, colour, fill style etc.). Normally in X there is a limited range of fonts (scaleable fonts are a recent addition), while in MS Windows an infinite selection of sizes is available thanks to the scaleable TrueType font system. Under XView and Motif, wxWindows chooses the closest matching font.

Recent releases of wxWindows remove some of the limitations of the panel/canvas separation, and now wxPanel inherits from wxCanvas, and has its own panel device context for drawing graphics on. XView does not directly support this model but wxWindows uses lower-level X calls to implement the functionality.

MDI versus SDI


MDI versus SDI

In MS Windows, a popular technique is to use the MDI (Multiple Document Interface) style, where the application window has a number of iconizable document windows which fit within it. This can save clutter on the desktop since iconizing or moving the parent window iconizes or moves all the child windows. MDI contrasts with SDI (Single Document Interface) in which windows are not constrained within one parent window, and normal practice is to run one instance of the application per document. Since wxWindows uses the large model, and large model programs may be limited to one instance at a time (unless only one data segment is used), it makes sense to offer MDI support. See Memory Models.

I have decided to include largely automatic, albeit relatively inflexible, support for MDI for these reasons:

In wxWindows, one argument of the frame constructor is used to indicate whether the frame is an SDI frame, an MDI parent frame or an MDI child frame. The default is to create an SDI frame. Once MDI frames are created, everything else is automatic, including appending the usual Window menu option, and moving a child menu to the parent frame when the child frame is activated. The choice of menu items for an MDI child frame will differ slightly, usually including menus (such as Quit) which would normally be on the main SDI window, but this only requires a small amount of extra application code.

An MDI toolbar is supported from release 1.61, by using the wxFrame::SetToolBar member function.

The demo program mdi shows how a program can easily be made switchable between SDI and MDI - use the -mdi command switch for MDI operation.