Upcoming Events
Unite 2010
11/10 - 11/12 @ Montréal, Canada

GDC China
12/5 - 12/7 @ Shanghai, China

Asia Game Show 2010
12/24 - 12/27  

GDC 2011
2/28 - 3/4 @ San Francisco, CA

More events...
Quick Stats
108 people currently visiting GDNet.
2406 articles in the reference section.

Help us fight cancer!
Join SETI Team GDNet!
Link to us Events 4 Gamers
Intel sponsors gamedev.net search:

  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

 

Window Messages

This section is the core of GUI implementation. Window messages are the events that get sent to a window when the user performs certain actions - clicking the mouse, moving it, hitting a key, etc. Some messages (like wm_keydown) are sent to the active window, some (wm_mousemove) are sent to the window the mouse is over, and some (wm_update) are always sent to the desktop, regardless.

Microsoft Windows has a message queue. My GUI does not - when calcall() figures out that it needs to send a message to a window, it stops right there and "sends" it - it calls the appropriate wm_xxxx() virtual function for that window. I've found that this method is just fine for simple GUIs. Unless you have a really good reason, don't bother with implementing a full-blown message queue, storing things into it, and having separate threads pick up the messages and dispatch them. For most game GUIs, it isn't worth it.

Also, notice that the wm_xxxx()'s are all virtual functions. This is where C++'s polymorphism is working for us. Need to change how certain types of windows (or controls - say, buttons) deal with a "left mouse button has just been pushed down" event? Simple, derive a class from the base window and override its wm_lbuttondown() method. The system will automatically call the derived class's method where appropriate; behold the power of C++.

As much as I'd like to, I can't go into very much detail about calcall(), the function that polls all the input devices and sends out the messages. It does many things, and implements many behaviors that are specific to my GUI. For example, you might want your GUI to behave like X-Windows, where the window the mouse is over is always the active window. Or, you might want to make the active window system modal (meaning nothing else can happen until the user gets rid of it), like several Mac-based programs do. You might want the ability to move windows by clicking anywhere in them, instead of just in their title bar, like WinAmp. The implementation of calcall() will vary wildly depending on which behaviors you decide to incorporate into your GUI.

I'll give you a hint, though - the calcall() function is not stateless, in fact, your calcall() function will probably end up being a rather complex state machine. The perfect example of this is dragging and dropping things. In order to properly calculate the difference between a normal "mouse button released" event, and a similar but completely different "whatever the user was dragging has just been dropped" event, calcall() must maintain a state. If you're rusty on finite state machines, save yourself a lot of headaches and brush up on them before you tackle calcall()'s implementation.

The wm_xxx() functions included in the window header file were the ones I felt represented the minimum set of messages a GUI would need to calculate and dispatch. Your needs may differ, and there's no reason why you have to stick to the Microsoft Windows set of messages; if a custom message would be perfect for you, now's the time to implement it.


Next : Wrapping it up...