Contents  Introduction  The Design  The Plan  Implementation  Window  Management  Coordinate  Systems  Window Drawing  Window  Messages  Wrapping it up  Printable version     The Series  Part I  Part II  Part III  Part IV

Coordinate Systems

One of the top priorities for my GUI was resolution independence, and what I call "stretchy dialog boxes." Basically, I wanted my windows and dialog boxes to scale themselves larger or smaller, depending on the screen resolution of the system they were running on. On systems with higher resolutions, I wanted the windows, controls, etc. to expand; on 640x480, I wanted things to shrink. Also, I wanted them to be able to fill their parent windows, regardless of the parent window's size.

What this really meant was that I needed to implement a virtual coordinate system, just like Microsoft Windows. I based my virtual coordinate system around an arbitrary number - I effectively said, "Henceforth, I will assume that every window is 10,000x10,000 units, regardless of the actual size of that window," and then let my GUI do the work of scaling the coordinates. For the desktop window, the coordinates are scaled to the physical resolution of the monitor.

I accomplished this through four functions: virtxtopixels(), virtytopixels(), pixelstovirtx(), and pixelstovirty(). (Note: only two are listed in the code; I figured you got the idea). These functions are responsible for converting between the virtual 10,000x10,000 unit coordinates and either the actual dimensions of the parent window, or the physical coordinates of the monitor. Obviously, the rendering functions of the windows use these functions heavily.

The screentoclient() function is responsible for taking an absolute screen position and converting it into relative virtual coordinates. Relative coordinates have their origin at the upper-left of a window; it's the same idea as world space and object space, in 3D. Relative coordinates are indispensable for dialog boxes.

All coordinates in the GUI system are relative to something. The only exception to this is the desktop window, whose coordinates are absolute. This relative way of doing things ensures that child windows move when their parents do, and that the structure of dialog boxes is consistent as the user drags them to different locations. Also, because our entire virtual coordinate system is relative, when a use stretches or shrinks a dialog box, all of the controls within that dialog will stretch and shrink also, automatically trying their best to completely fill up their new dimensions. This is an amazing trait, for those of us who have ever tried to do the same thing in Win32.

Finally, the findchildatcoord() function takes a (virtual) coordinate and determines which child window (if any) is under that coordinate - useful, for example, when a mouse button is clicked, and we need to know which window to send the button click event to. The function works by looping through the subwindow array backwards (remember, the topmost window is at the back of the array), doing some rectangle geometry to see if the point is in that window's rectangle. The flags parameter provides some extra conditions for determining if a "hit" occurred; for example, when we start implementing controls, we'll realize that it's often useful to prevent label and icon controls from registering a "hit," instead giving the windows beneath them a chance at the test - if a label is placed on top of a button, the user can hit the button, even if technically, they're clicking on the label. The flags parameter controls those special cases.

Now that we've got some coordinates, we can finally begin to draw our window…

Next : Window Drawing