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

The Plan

I took the following steps when I implemented my GUI:

1. First I coded some basic window management code. This chunk of code is responsible for the window tree, adding / deleting windows, showing / hiding them, moving them to the top of the Z-Order, etc. I stubbed out the window drawing procedure by simply drawing rectangles where my windows should be, then drawing a number in the top-left corner of them to indicate their z-order.

   Understand up front that your life will become tremendously easier if you buy or make a good, solid, template class for arrays of pointers. The STL (Standard Template Library) that ships with most versions of C++ has several good template-able pointer array classes, but if you want to make your own, do it formally - test it thoroughly and completely before you start implementing your window manager. The last things you need right now are subtle memory leaks or null pointer references caused by a shoddy array class.

2. Once I had basic window management functions, I spent some time thinking about my coordinate systems. Coded up some coordinate management functions.
   
   

3. Next, I tackled the window drawing code. I derived a "fancy window" class, and showed it how to draw itself using a set of nine sprites - four sprites for the corners, four sprites for the edges, and one sprite for the background.

   Using nine window sprites, it's possible to create windows that sport a unique, artistic appearance, and yet are still dynamically re-sizeable (ala StarDock's WindowBlinds). The downside to this is that you'll need a fairly smart drawing library, one that can handle tiling sprites, stretching them, and centering them, as well as a very complex window creation program (something the artists can use to construct their windows), to really make this method work well. And, of course, you'll pay in window drawing speed, too.

4. Once the drawing code for the generic window was complete, I started implementing the controls. Coding controls is straightforward, but again, requires very thorough testing. I started with the simple controls: statics, icons, etc., and worked my way up from there, as explained earlier.

5. Finally, after all of my controls were complete, I coded up a simple Resource Editor, a program that allows someone to graphically place controls and layout dialog boxes. The resource editor took me a good month to do, but I highly suggest doing it (instead of just using text files to position stuff) - it's much easier to create dialog boxes graphically, and it was a good exercise: during development I uncovered several bugs in my controls' code, things that would have proven very difficult to catch in the actual game.

   I toyed, for a very long time, with the idea of creating a program that would convert an MSVC++ resource (.RC) file into a custom resource file useable by my GUI. In the end, I decided such a program would be more trouble than what it would be worth. The whole reason I was writing a GUI was to get away from the confines of Windows, and to truly do that, I needed my own editor, tied to my own resource file format and my own way of doing things. I decided to implement a WYSIWYG Resource Editor in MFC from the ground up. My needs, my decision; your needs may be different. If anyone out there tries to write a converter, I'd love to hear about it.

Where to now? The rest of this article will explore the first two steps. Part III of this series will go into mind-numbing detail about coding controls. Part IV will talk a bit about implementing a resource editor and serializing windows.

So... let's start with step one: basic window management functions.

Next : Implementation