The tutorials start with the most basic Windows program, the windows equivalent of "hello world!", Winnie. Then we move on to a more Generic program, which serves as a skeleton for a simple Windows application. Then we discuss various Controls. Using these controls one can build a complete dialog-based application, whose main window is a dialog. We are then ready to discuss a Generic Dialog, a framework with which one can quickly build specific dialogs.

To do some simple graphics one needs a Canvas object. You use Pens and Brushes to paint on the canvas.

More advanced topics include programming with Threads with a practical example of a Folder Watcher — a program that watches directories for changes.

Modern windows programming requires some knowledge of the Shell API, which leads us to the discussion of OLE and COM. We show how one can encapsulate OLE in C++ to create Smart OLE. OLE is also used in Automation, which lets your application talk to other applications.

Controls are nothing but specialized windows. You can easily create your own controls, as evidenced by the Splitter Bar tutorial.

For graphics programmer, we give a short introduction on using Bitmaps for animation and a more advanced tutorial on using Direct Draw.

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.

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.

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.

The GetMessage API is an interesting example of the bizarre microsoft Troolean (as opposed to traditional, Boolean) logic. GetMessage is defined to return a bool, but the documentation specifies three types of returns, non-zero, zero and –1. I am not making it up! here's an excerpt from the help file:

• If the function retrieves a message other than WM_QUIT, the return value is nonzero.

• If the function retrieves the WM_QUIT message, the return value is zero.

• If there is an error, the return value is -1.

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.