Книга: Windows API Tutorials

The Simplest Windows Program

The Simplest Windows Program

Before you can even begin thinking about programming in windows, you have to be able to understand how this simple program works. Remember to compile this and other windows programs with the STRICT compilation flag defined!

Note: This is a Win32 program — it will run under Windows 95 and Windows NT (if they want you to program for the 16-bit platform, they should pay you twice as much!). Windows API calls are highlighted in blue and windows specific data types are shown in green. I will also usually put a double colon in front of API calls. In C++, that simply means that i'm calling a global function, in case there is some ambiguity.

Remember to compile sources as a Windows application. For instance, in Visual C++ select File.New.Projects.Win32 Application. Otherwise you'll get the error: unresolved external _main. (I provided a project file for those of you who use MS VC++ 6.0)

First, you have to define a class of windows that will be displayed by your application. In our case we will display only one window, but still, we need to give Windows some minimal information about its class. The most important part of the WinClass is the address of the callback procedure, or the window procedure. Windows is supposed to call us —it sends messages to our program by calling this procedure.

Notice the declaration of WindowProcedure. windows will call us with a handle to the window in question, the message, and two data items associated with the message, the paramters, wparam and lparam.

In WinClass we also have to specify things like the program instance handle HINSTANCE, the mouse cursor (we just load the standard arrow cursor), the brush to paint the window's background (we chose the default window color brush), and the name of our class.

Once all the fields of WNDCLASS are filled, we register the class with the Windows system.

#include <windows.h>
LRESULT CALLBACK WindowProcedure(HWND hwnd, unsigned int message, WPARAM wParam, LPARAM lParam);
class WinClass {
public:
 WinClass (WNDPROC winProc, char const * className, HINSTANCE hInst);
 void Register () {
  ::RegisterClass (&_class);
 }
private:
 WNDCLASS _class;
};
WinClass::WinClass(WNDPROC winProc, char const * className, HINSTANCE hInst) {
 _class.style = 0;
 _class.lpfnWndProc = winProc; // window procedure: mandatory
 _class.cbClsExtra = 0;
 _class.cbWndExtra = 0;
 _class.hInstance = hInst; // owner of the class: mandatory
 _class.hIcon = 0;
 _class.hCursor = :: LoadCursor (0, idc_arrow); // optional
 _class.hbrBackground = (HBRUSH) (COLOR_WINDOW + 1); // optional
 _class.lpszMenuName = 0;
 _class.lpszClassName = className;
// mandatory
}

Once the Window Class is registered, we can proceed with the creation of a window. This is done by calling the CreateWindow API. It takes a lot of arguments, the name of the window class that we have just registered, the caption that will appear in the title bar, style, position and size, and the application instance. the rest of the arguments, for the time being, will be left equal to zero.

The window will not appear on the screen until you tell Windows to show it.

class WinMaker {
public:
 WinMaker (): _hwnd (0) {}
 WinMaker (char const * caption, char const * className, HINSTANCE hInstance);
 void Show (int cmdShow) {
  ::ShowWindow (_hwnd, cmdshow);
  ::UpdateWindow (_hwnd);
 }
protected:
 HWND _hwnd;
};
WinMaker::WinMaker (char const * caption, char const * className, HINSTANCE hInstance) {
 _hwnd = :: CreateWindow (
  className, // name of a registered window class
  caption, // window caption
  WS_OVERLAPPEDWINDOW, // window style
  CW_USEDEFAULT, // x position
  CW_USEDEFAULT, // y position
  CW_USEDEFAULT, // witdh
  CW_USEDEFAULT, // height
  0, // handle to parent window
  0, // handle to menu
  hInstance, // application instance
  0); // window creation data
}

A Windows program is event-driven. It means that you, as a programmer, are supposed to be on the defensive. the user will bombard windows with various input actions, and windows will bombard your program with messages corresponding to these actions. All you have to do is to respond to these messages. The picture below shows schematically how it works.

Windows gets various events from the keyboard, the mouse, the ports, etc. Each event is quickly converted into a message. Windows dispatches messages to appropriate windows. For instance, all keyboard messages go to the window that currently has the input focus (the active window). Mouse messages are dispatched according to the position of the mouse cursor. They usually go to the window that is directly under the cursor (unless some program captured the mouse).

All these messages end up in message queues. Windows keeps a message queue for every running application (actually, for every thread). It is your duty to retrieve these messages one-by-one in what is called a message loop. Your program has to call GetMessage to retrieve a message. then you call DispatchMessage to give it back to windows. couldn't windows just go ahead and dispatch all these messages itself? in principle it could, but a message loop gives your program a chance to have a peek at them and maybe perform some additional actions before dispatching them. or not…

Each message is addressed to a particular window. When you tell Windows to dispatch such a message, it will figure out the class of this window, find the associated Window Procedure, and call it. Every single message sent to our window will end up in our window procedure. It is now up to us to react to it. So, do we have to respond appropriately to every possible type of Windows message? There a hundreds of them! Fortunately, no! We only need to intercept these messages that we are interested in. Everything else we pass back to Windows for default processing using DefWindowProc.

Let's have a look at WinMain. the execution of a windows program doesn't start in main-it starts in WinMain. First, we create a winclass and register it. Then we create an actual window (of the class we've just registered) and show it. Actually, WinMain is called with the appropriate show directive — the user might want to start the application minimized or maximized. So we just follow this directive. Next we enter the message loop and keep retrieving and dispatching messages until GetMessage returns 0. at that point the message's wparam will contain the return code of the whole program.

int WINAPI WinMain (hinstance hinst, hinstance hprevinst, char * cmdParam, int cmdShow) {
 char className [] = "Winnie";
 WinClass winClass (WindowProcedure, className, hInst);
 winClass.Register ();
 WinMaker win ("Hello Windows!", className, hInst);
 win.Show (cmdShow);
 MSG msg;
 int status;
 while ((status = :: GetMessage (& msg, 0, 0, 0)) != 0) {
  if (status == –1) return –1;
  :: DispatchMessage (& msg);
 }
 return msg.wParam;
} 

The other part of a Windows program is the Windows Procedure. Remember, Windows will call it with all kinds of messages. All these messages can be ignored by sending them to DefWindowProc. There is only one message that we must intercept. That's the WM_DESTROY message that is sent by Windows when the user decides to close the window (by pressing the close button in the title bar). The standard response to WM_DESTROY is to post the quit message and return zero. That's all there is to it.

// Window Procedure called by Windows

LRESULT CALLBACK WindowProcedure (HWND hwnd, unsigned int message, WPARAM wParam, LPARAM lParam) {

 switch (message) {

 case WM_DESTROY:

 :: PostQuitMessage (0);

 return 0;

 }

 return :: DefWindowProc (hwnd, message, wParam, lParam);

}

This is actually the ugliest, least object oriented part of encapsulating Windows. It's getting better from this point on. Like in this generic Windows program.

Оглавление книги