Developing a GUI in C++ and DirectX

This function is recursive, and looks like this in PDL:

void gui_window::load(int filehandle) {

 // read window properties (colorsets, etc.)

 // read total number of children for this window

 // for each child…

 // read window ID from disk

 // new a gui_window derivative based on that ID

 // tell the newly created window to load itself (recurse)

 // next child

}

In other words, you’d load windows from disk exactly as you would expect. First, you take care of the base window: read in its properties. Then, read in the total number of children of the base window. For each child, read an ID byte, new up a window based on that ID, and then tell that new window to load itself (recurse down into it). Once all of your children are loaded, you’re done.

Of course, it’s also very important that your file structure mirrors this same layout. Make sure your save code saves things in the same order that you’re loading them.

Resource Editors

To really make your game GUI shine, you’re going to need a resource editor. Certainly you don’t need one as slick and functional as Developer Studio’s, but you at least need a basic application that will let you add, edit, delete, and arrange things, and will save you the trouble of calculating out virtual coordinate positions for all of the controls in your dialogs.

Writing a full-featured, WYSIWYG resource editor is beyond the scope of this article, but I can give you a few miscellaneous tips for if you do decide to attempt such a beast:

· Share your code. Specifically, make the resource editor share the same rendering code as your actual game. This way, you get WYSIWYG support, and you save yourself the trouble of having to implement two sets of GUI code. I guarantee you, it’s easier to tweak your DirectX code so that it renders to a GDI surface instead of to a double-buffered system than it is to re-implement an entirely new drawing core. Remember also that it’s quite likely your GUI system will change over time - you don’t want to constantly have to change code in two different places.

· Don’t try to emulate DevStudio’s look and feel. In other words, don’t waste time trying to figure out how to mimic the various features of the DevStudio GUI (like, say, tabbed property sheets and preview windows). Don’t feel bad if your Resource Editor is ugly in comparison; yes, it’s true that the productivity of a team is directly proportional to how useful its tools are, but at the same time, it’s very unlikely that anyone outside your team will be using your Resource Editor, and you’re not using it to create a full-fledged GUI app; you’re just making a few dialogs. You don’t need context sensitive help. You don’t need context menus, unless in your opinion they ease a particularly tedious operation. It’s OK if your resource editor isn’t polished, just so long as it gets the job done.

· Emphasize data integrity over speed. The Resource Editor is a data wrangler, not a high-performance app, and there’s nothing more annoying than when a dialog you’ve spent an hour designing goes down the tubes because of a program crash. When writing your GUI, preserving data should be your highest goal - implement autosaves, undo buffers, etc, and go easy on the optimization.

Subclassing

Those of you who are familiar with the way Win32 does its windowing probably already know what the term “subclass” means. For those of you who don’t - when you “subclass” a window, you effectively “derive” a new window type, and then wedge your new window type into places where the old window used to be.

Let me explain that a little better. Say we need a Super Listbox. We’ve got a normal listbox class, but it just doesn’t cut it for some reason; our game demands the Super Listbox. So we derive a new “super listbox” class from our regular listbox class. So far so good.

But how do we place the Super Listbox in our game’s dialog? Since the Super Listbox is specific to our application, it wouldn’t make sense for us to add functionality to our resource editor to support it. But, at the same time, how do we tell our GUI system that for this one particular instance (our game), we’d like all listboxes to really be Super Listboxes? That’s what subclassing is all about - it’s not an exact, technical definition, but it will suffice for now.

The approach I’m about to illustrate is what I call “subclassing at load time.” To understand it, let’s start with the basic loading code I described in the last section. We’ve got a load function, which recursively news, loads, and then adds windows. Specifically, we’ve got something that looks like this, in PDL: