As a designer, your work with windows in PenPoint involves creating them and inserting them into the window hierarchy, showing and hiding them, laying them out, managing them in the context of your application, and filing them.
The Pen Point Windowing System
Creating a Window
As we have indicated previously, you generally will start the window-creation process by creating a subclass of clsWin or by using an existing subclass.
You may also subclass or create a subclass of clsGWin, particularly if your application needs to respond to gestures the user makes with the pen.
Once you have decided which class to work with, you create a new window by sending that class the message msgNew. The class returns a window (or WIN) object. When you send msgNew, you must supply a WIN_METRICS structure as an argument. Although we discuss this data structure later in the chapter in detail, it is useful for you to know the kind of information it requires you to furnish. At a minimum you must tell PenPoint the following information about your new window:
• its parent or device
• its size and location (bounds) relative to its parent
• flag settings that determine such things as how layout, clipping, and repainting are to be handled, and what kind of input it may receive
Now that you have created this new window, it is only an object. You must insert it into the window hierarchy. You do this by sending message
msgWinlnsert, supplying a WIN_METRICS structure for the window as an argument. This inserts your window as a child window; if you wish it to be a sibling window (in other words, at the same level as another window in the hierarchy), then you can send msgWinlnsertSibling. Generally, when you are inserting a subtree of a window tree, you should create the window that will be the root of the subtree first, without inserting it. Next, create its children and insert them into it. Only when the entire subtree has been created should you insert its root window. When the parent window is inserted then its child win-dows appear on the display. This has the effect of allowing you to create all your windows off-screen and to then display them simultaneously.
Showing Windows
Just because you've created a window and inserted it into the hierarchy, its graphic contents are not automatically visible. You must ensure that the wsVisible flag in the WIN_METRICS structure described later in the chapter is set to True if you want the window to appear on the display.
Furthermore, child windows are only visible if their parent window is visible.
Therefore, you must make sure that the parent window is visible first, even when the child window's wsVisible flag has been set. This is due in part to two basic rules about parent and child windows
• Children are always on top of the parent.
• Drawing in a child window is always clipped by the parent. (We'll have more to say on this later.)
By the way, this chain of windows into which all windows are inserted goes all the way back up the hierarchy to theRootWin, which we mentioned earlier.
With your windows properly inserted into this hierarchy, PenPoint can now give you a great deal of help in managing your windows, as we'll see later. For example, it keeps track at all times of which windows are "dirty" (that is, those that need repainting) because they have been moved or resized or obscured or revealed after being obscured or had other events happen to them.
PenPoint includes a flag in WIN_METRICS that is particularly interesting as we discuss the tree hierarchy of windows. If you insert a window into the hierarchy and later remove it (when the user closes it, for example), it may uncover a window that had been beneath the newly removed window. This now unobscured window must be repainted. This process can take time, but you can save time by setting the . wsSaveUnder flag in WIN_METRICS to True. When this is set, the window creates a
copy of the physical screen region underneath the screen area where newly inserted window will be displayed. This means that when it is time to repaint the screen area under the newly inserted window, PenPoint doesn't need to send a message to the formerly obscured window or wait for it to process such a mes-sage. It simply copies the bit image stored when it was inserted. You can see this process in operation when you retract a PenPoint menu; the screen beneath the menu window is instantly redrawn. It is better to use this flag for windows that you expect to be on the screen for a brief time and only when you are sure the contents of the windows under yours will not change while your window is displayed.
Laying Out a Window
Because the layout of child windows is controlled by the parent, the over-riding issue in window layout is the relative positioning of children within a parent. Like any good parent-child relationship, this process involves negotia-tion. There are three attitudes a parent window can be designed to take toward how child windows lay themselves out within its borders
• Permissive. Using this model, the parent window is set up so that child windows can display themselves anywhere, even to the point of completely covering the parent window.
• Strict. With this approach, the parent makes all the decisions. The parent window is given an opportunity to intercept and veto all messages to its child windows that could affect layout.
• Flexible. If you program this attitude into your parent window, it will attempt to meet child windows' layout requests but can override them if those mes-sages result in layout conflicts that the parent window has been designed to prevent.
Window layout is far more complex than meets the eye. Much of the work in this area of your PenPoint design is handled through the User Interface Toolkit, particularly its clsLayout (see Chapter 10), so we will not attempt to deal with the issue in depth here.
Managing Windows
Because of the object-oriented way PenPoint deals with window layout, you'll find that handling such things as the resizing of your windows is straightforward. As far as the system is concerned, such activities require laying out thewindow anew. So the process of repainting the screen after a window is resized is for all practical purposes, identical to the original process of laying out the window.
Sometimes you will want to adjust or modify some or all of the child windows in your parent window. You can use the process of enumeration to obtain a list of all immediate child windows or all windows (recursively, including grand-children, great-grandgrand-children, and so forth) contained in your parent window.
Depending on how you ask for this information, you can also obtain basic information about these windows (such as their UIDs and the style flags).
There are times when you want to arrange child windows in a predetermined sequence. In that case, PenPoint supplies a message, msgWinSort, that permits you to do so. You tell PenPoint how you want the sort handled by providing a callback routine that compares two windows. PenPoint then will rearrange the child windows according to the instructions in that routine.
Filing Windows
When the user turns away from a page in the Notebook or closes a floating window, a parent window may need to file its state and contents. When you file a window in PenPoint, you usually file its child windows as well. This means that you often may find yourself filing many more windows than you thought you were filing.
The PenPoint Windowing System
Some child windows may set a style flag that prevents their being filed. This , is done, for example, with temporary windows that are going to be re-created
the next time they are needed. The important thing to remember is that all windows are given the opportunity to file when your application is told to save its state.
PenPoint keeps track of the window environment (such as the orientation of the device, pixel size, default system font and size, and other data) for you.
When your application must open a window it previously saved, it has access to this environmental information so that recalculating position and orientation is simple if you even need to use it. If nothing has changed since the window was saved, you do not need to do anything.
Summary
This chapter has examined the windowing system in PenPoint, focusing on the most common behaviors of this most visible element of the user interface.
It has examined the basic components of windows and the various coordinate systems used to identify the locations of objects within the system.
As a designer, your involvement with windows includes their creation, insertion into a window hierarchy, showing and hiding them, laying them out, managing them, and filing them.