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
106 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
 GUI Controls
 We'll Need

 Breaking It Down
 Static Controls
 Pushbuttons
 Carets and The
 Textbox Control

 Progress Bars
 Sliders and
 Scrollbars

 Listbox Control
 Conclusion

 Printable version

 


  The Series

 Part I
 Part II
 Part III
 Part IV

 

The Static Controls

There are three kinds of static controls we'll be looking at: static text controls, static icon controls, and frame controls. All three of these controls are very easy, because they take no messages - all they do is draw themselves at certain positions.

Static text controls are by far the easiest control you'll ever implement - just draw your window's caption at the upper-left of your window, and you're done. If you're especially through, you might want to add code to justify your text a certain way - for example, to center your text in your client rect, you might employ the classic centering algorithm - take the width of your window, subtract the width of the text you're going to draw, and divide by two, telling you how many pixels "in" (that is, how many pixels right from the left window edge) to start drawing.

Static icon controls are a little tougher. Actually, the term "static icon control" is a bit of a misnomer, given that we want our icon controls to be able to animate. Even so, implementation of these icon controls isn't tough, provided you've got a solid sprite library to handle all the details of implementing animation: checking the millisecond delta between this frame and the one that's on the screen now, using this delta to determine how many frames your sprites should advance by, etc.

Icon controls only become painful to implement if you're not redrawing your entire GUI system every frame. In this case, you've somehow got to deal with clipping the icon control, so that even though it's being drawn every frame, it doesn't accidentally overwrite pixels belonging to a window that's sitting on top of it (but wasn't changed, so therefore wasn't drawn). I didn't implement this - my GUI gets redrawn every frame - but if you're faced with this problem, you might want to try setting up a clip list for each icon, using it to draw the icon, and re-evaluating it when any window is moved, closed, or opened. This may or may not be a viable solution - I just dreamt it up while writing this - but it seems to be at least a good jumping off point.

Frame controls are also pretty straightforward. I implemented my frame control by drawing a border around m_position, then drawing the window caption at about position (5,5), in client coordinates (that is, about five pixels right and five pixels down from the upper-left of the frame control), but you may decide you want something a little fancier.

The one complex thing you might want to do for your static controls is to change the behavior of the findwindow function slightly so that it "skips" all windows that are static controls. That way, if a static text control is sitting on top of a pushbutton, the user will be able to push the button "through" the static control. I've found this to be especially valuable if you're implementing "easy-move" windows - windows that you can move by grabbing anywhere, not just in the title bar, ala WinAMP.

Now let's take a look at how to implement buttons.


Next : Pushbutton Controls