DISCUSSION

Your application calls the InitFloatingWindows function--instead of the InitWindows function--to initialize the Window Manager and enable automatic front-to-back display ordering of all your application's windows.

Windows can be placed on the display screen so that one window appears to be behind another. This visual overlapping gives the user an impression of depth. A floating window is so-named because its front-to-back display order (that is, its z-order placement relative to other windows on the screen) makes it appear to float in front of document windows.

Because earlier versions of the Window Manager only defined the look of floating windows, not their floating behavior, some applications contain code that implements a floating effect for tool palettes and other such windows. However, your application can now use the Window Manager to automatically sort floating and non-floating windows into separately z-ordered groups, thereby enforcing the proper front-to-back display order.

The Window Manager only enforces display ordering for windows belonging to applications that have explicitly requested this functionality by calling the InitFloatingWindows function. Therefore, if you wish to make use of the system-supplied "floating" behavior, you must call InitFloatingWindows to initialize the Window Manager, not InitWindows . If you use InitWindows to initialize the Window Manager, floating windows intermingle with non-floating windows, and your application is still responsible for ensuring that floating windows remain higher in z-order than non-floating windows. However, if you use InitFloatingWindows , the Window Manager automatically ensures that floating windows remain higher in z-order than any non-floating window. When your application calls InitFloatingWindows , the Window Manager sorts each of your application's windows into one of three window display layers: modal, floating, and document.

For windows created with the Mac OS 8.5 function CreateNewWindow , the order in which the Window Manager sorts the windows is based on window class. See Window Class Constants for a description of the various window classes (for a floating window, kFloatingWindowClass ) which determine sort order for windows created with CreateNewWindow .

For pre-Mac OS 8.5 windows, the sort order is based upon window definition ID. For example, if your application calls InitFloatingWindows , then calls the GetNewWindow function with a dboxProc window ID, this produces a dialog box located in the modal display layer. A similar ordering is imposed for floating and document window definition function IDs.

To obtain system support for floating windows, before using any other Window Manager functions you must initialize the Window Manager by calling the InitFloatingWindows function. As with InitWindows , before calling InitFloatingWindows , you must initialize QuickDraw and the Font Manager by calling the InitGraf and InitFonts functions, respectively.

Also, before calling the InitFloatingWindows function you should always confirm that InitFloatingWindows is supported by the version of the Mac OS upon which your application is running. To do this, check the value returned by the Gestalt function to ensure that the gestaltHasFloatingWindows bit is set, as described in Gestalt Constants .

As part of initialization, the InitFloatingWindows function creates the Window Manager port, a graphics port that occupies all of the main screen. The Window Manager draws your application's windows into the Window Manager port. Your application should not draw directly into the Window Manager port, except through custom window definition functions.

Note that the functions HideFloatingWindows and ShowFloatingWindows require you to call InitFloatingWindows prior to their use.

VERSION NOTES

Supported with Mac OS 8.6 and later.