Select page Next page

Objectives

To enable programs to be easy to construct and maintain, the expert would tell you to use procedures wherever possible. You have already seen how to create a sort of procedure in the event handler you made in the last chapter. In this chapter, then, we're going to take what we learned then and to advance it a little further. In doing so, we will acquire other knowledge, too. Specifically, we will start to use controls such as buttons and find out how to handle them in code. To enable us to do all of this, you will need to be able to:

Using static controls

The best way of learning new material is by means of an example. So, let's look at a little event handler that you should find useful. We will expand on it further in the next chapter, too.

If you look at any commercial applications today, you might be tempted to think that the positions of the various buttons and other controls are determined by the whim of the designer at best and completely randomly, at worst. But this is far from the case. Applications are normally designed so that the most important things are up at the top left of the screen and the least important ones towards the bottom right. You are expected to work your way left to right from the top of the screen to the bottom right. When the screen designer puts this together, he has to have an idea of how the application will be used in order to place these controls in that sort of order.

This is the science of ergonomics. It makes sense, therefore, to have our "Exit" button down at the bottom right of the client area. Ah, but how do we keep it there, relative to the bottom right corner of the screen? If the user resizes the screen, making it smaller, the button will disappear and if he stretches the window, there will be a great ugly gap. You can see this in the animation on the right. So how do we "peg" it to a relative position?

With the sort of information we have acquired in the course of this chapter, I'm sure you can see that the button is simply not alive to the fact that the window has resized. Otherwise, we could do something about it. You can see where I'm going with this - we need to catch the WM_SIZE event and, in the handler, move the button to a new location, relative to the bottom corner of the window.

Start a new project, then, Call the project "pegButton", de-select "Add symbolic information" and then rename the window to "winMain". While your changing the window's name, there's something else you could do, too. Scroll down the attributes for the window until you find the one called "ScaleMode". This defines the units to be used when "measuring" a window. It's a bit like deciding something will be measured in yards or metres. It's normally set to "twips" (a twentieth of a point) which is a typographical convention for PostScript purposes. But we won't be printing anything - we need to determine the position of the button on screen and update it. That means we need pixels.

Now it's time to put a button on the screen. You do this very simply by clicking the little button icon in the toolbox at the left side of the EasyCode window (it has the "OK" text) and then either clicking once in the design window to get the default-sized button or dragging the cross-hairs to make it the actual size you want. For our purposes, it doesn't really matter what size it is - just make it something like the illustration here. Make sure it is still selected (the little boxes around the edge of the button - these are normally called "grab handles") and go over to its properties. Change its name to btnExit" and its text to "Exit".

I should really point out here that it's really important that you choose the names for your windows and controls with care. If you remember from Chapter 1, the name of the main loop is "built up" from a combination of the name of the window and the word "Procedure". A similar thing happens with controls to enable EasyCode to keep track of them. For example, we may have several windows, each with many buttons. How does EasyCode know which button belongs to which window - they're all just stored in those little boxes in memory. What happens is this - EasyCode assigns a "serial number" to each control as it is created. This serial number has a name built up from the abbreviation "IDC", the name of the parent window and the name of the control, all in upper case and separated by underscores. So, since our window is called "winMain" and our button is called "btnExit", its serial number (or "ID") is IDC_WINMAIN_BTNEXIT. This isn't a Win32 handle (there is a function call to get the handle, given the ID), it's just a way for EasyCode to keep track of things.

Select page Next page