The PenPoint document frame has many constituent parts, each of which is at least one window. Figure 7-1 shows the various components of such a document frame. This is the type of document frame the user understands by the term "window." Of course, as we have already indicated, there are many other windows in a PenPoint application that the user would not be as likely to recognize as a window.
title line menu bar
Proof .. .
Find .. . i
~
scrollbarbodyo~
document
Spell .. .
resize
handles!
ma~~~~---""'I-···"""""""""'''''""''-··_···_···+~
Figure 7-1 Typical Window and Its Parts
You can choose not to use some of these parts, depending on your window's functions. Within an application, you may have several windows, each of which uses different elements of a typical window. You make deci-sions regarding which parts to use; it's a matter of choosing the right class to subclass or instantiate.
The Pen Point Windowing System
Figure 7-2 shows the windowing portion of PenPoint's class hierarchy. As you can see, it is quite complex. On closer examination, however, you can see that typical parent windows (those that contain other windows shown in Figure 7 -2) are derived from the top level of the hierarchy. The class clsGWin is a gesture-interpreting window class; clsEmbeddedWin supports embedded windows.
(TheRootWindow ~ clsWin cls()Nin
Figure 7-2 Windows Class Hierarchy
Notice that there is a special instance of clsWin called theRootWin in Figure 7-2.
This window is always present in the PenPoint windows hierarchy because it is part of the way the system organizes itself. You can think of theRootWin as the display of your system.
While windows are normally thought of in relation to a computer display, PenPoint window trees can be rooted to any image device. As a result, win-dow trees can be used to create virtual, in-memory displays. An important consequence of this design is that window trees can be rooted on printing devices. The printed image is constructed in memory as a window tree with graphics in each window, and the entire page image is then sent to the printer.
Because PenPoint allows the same window and graphics systems to be used for printers and displays, applications get printing behavior at virtually no cost.
It is generally not terribly useful to create instances of clsWin because this class does not know how to process input or repaint itself. You will probably find yourself most often creating a subclass of clsView or clsEmbeddedWin when you create your application's main window.
As we indicated earlier, windows do not know how to draw on the screen directly. You can view them as canvases, which can display themselves, and assuming you give them the appropriate behavior by subclassing or overrid-ing, repaint"themselves on demand. But they do not know anything about how to display images on the screen.
Drawing is handled via something called a drawing context. You create a drawing context and bind it to a window, then send drawing messages to the context, which translates those messages into ink on the display within the window to which it is connected. There are a number of significant advantages to this approach, three of which are worth mentioning here
• It minimizes memory consumption. PenPoint windows are lightweight (occu-pying about 100 bytes each), which means you can afford many of them.
Drawing contexts, on the other hand, take a minimum of about 500 bytes.
• It allows you to carry drawing state from window to window. You simply bind an existing drawing context to a different window.
• It sets the stage for image-model independence. If for some reason you wanted to draw with an imaging model other than the PenPoint default drawing context (for example, a custom model of your own) you can do so. This provides a measure of flexibility not usually offered by other windowing systems.
The PenPoint windowing system involves the use of five different coordinate systems, four of which will be of some concern to you as a designer. Figure 7-3 shows the five coordinate systems with a sample application running.
There are five coordinate systems because different levels of software have different needs and it is most efficient for code to deal with a coordinate system that accurately maps into its needs. Otherwise, expensive mathematical conversions would have to be performed too frequently. To understand each coordinate sys-tem, you must know both its user and its unit of measurement.
LUC (Logical Unit Coordinates) Coordinate system of drawing context. Use whatever units, origin, and rotation that are most convenient for your drawing.
LWC (Logical Window Coordinates) Coordinates in device units relative to your window: (0,0) is its lower left corner.
PWC (Parent Window Coordinates) Coordinates in device units relative to parent window.
LDC (Logical Device Coordinates) Device units transformed so that origin is in lower left corner). Takes into account rotation of the Lombard (Landscape mode).
DU4 (Device Units 4th Quadrant) The coordinate system used by the imaging primitives and the display hardware.
Figure 7-3 Window System Coordinates
The PenPolnt Windowing System
The two lowest-level coordinate systems (OU4 and LOC) are really only of concern to PenPoint; we will not deal with them here.
Of greatest interest to you, since they're used for most drawing, rendering, and general measurements within your own window, are Logical Unit Coordi-nates (LUCs). This is the coordinate system that the drawing context uses. It can measure in much higher resolution than pixels, which permits it to perform transformations with minimal rounding errors and allows it to render accurately on high-resolution output devices such as laser printers.
Furthermore, LUCs are very flexible because you can
• set the size of LUC units to whatever is most convenient and efficient for you, choosing from such measurements as points, metric, mils, twips, screen pixels, and pen-tracking pixels
• scale LUC units (so that one unit equals one inch, for example)
• change the origin (0,0) to a point other than the default lower left corner of the window (a process referred to as translation of the origin)
• rotate the coordinate system
All of this flexibility is well beyond what is necessary to describe the posi-tions of windows, which cannot be translated, rotated, or scaled, and which do not need fine precision in their placement. As a result, windows use pixels for their measurements.
Window coordinates come in two flavors: logical and parent. Logical Win-dow Coordinates (LWCs) are local to the winWin-dow in question; they describe the position of an object (typically a child window) inside the window. If you want to measure where your window is relative to its parent, use Parent Win-dow Coordinates, which are nothing more than your parent winWin-dow's LWCs.
Your parent window would, of course, use its parent LWCs, and so on up the window hierarchy.