Win32 is necessary for development in many current technologies. Some of my current projects utilize Win32/C++ applications. Many of them use a similar pattern for starting the application. Initializing the window that hosts these applications is not particularly interesting, but it is a foundation block for some of my applications that I will share in the future.
In Win32 UI programs there will be at least one function defined that is known as being of type WNDPROC. A WNDPROC is a callback function. It is the primary function through which Windows will communicate to an application various events. When a user moves their mouse over an application WNDPROC is called. When the user presses a key WNDPROC is called. When an application is being notified to render its UI again WNDPROC is called. The call signature for WNDPROC is shown below.
LRESULT CALLBACK WindowProc( _In_ HWND hwnd, _In_ UINT uMsg, _In_ WPARAM wParam, _In_ LPARAM lParam );
The first argument in this function is a handle to the window that is the intended recipient of the message. An application could have more than one window. But an application with only one window will have the same value. The second argument is a numerical value that identifies the event or message being sent. The constants that define possible vales generally are prefixed by WM_ (meaning Windows Message). Examples of such values include: WM_COMMAND, which is generally the result of a button being clicked; WM_PAINT, which tells the application to redraw its UI; WM_SIZE, meaning that the window has been resized; and WM_CLOSE, meaning that there was a request to close the window.
Because of the central position that the WNDPROC function plays in receiving notifications from the operating system, if all responses to the operating system were handled here the function would quickly grow big. I have seen this done, and it can get to be a nightmare on shared projects. One way to deal with this is to have the WNDPROC function act only as a method that routes these incoming messages to other functions that handle the method. A simple way to implement this is with a switch statement where each case does a minimal amount of work before passing the message on to a function specifically made to handle the message.
That is the solution used in the projects I plan to share in the future. I created an abstract base class named AppWindow that creates an application window; has a few methods for handling certain Windows messages; and has case statements for calling those methods in response to a Windows message.
Windows communicates these messages to an application through a message queue. An application must retrieve the next message to begin processing it. If an application does not retrieve any messages for a certain period of time, then Windows assumes the application is locked up or busy and may give you a prompt to either terminate or wait for the program. To keep messages going through the queue an application must implement a message pump. In a simple implementation of a message pump two functions are called in a loop. GetMessage which receives a MSG struct containing the information on a message and DispatchMessage to have the message handed off to the application’s WNDPROC for processing.
If there are no messages available, calling GetMessage will result in the application waiting until there is a message. During this wait, the main thread of an application will not use any CPU bandwidth. In some applications, such as games or other applications that are continuously performing UI updates, using GetMessage is undesirable since it can cause the UI thread to wait. In such applications, PeekMessage can be used instead. With PeekMessage, unlike GetMessage, if there are no messages available PeekMessage will not block. Its return value indicates whether or not a new message was available. If there are no messages to be processed the application can perform other tasks.
An application may modify a message within the time that it was retrieved with PeekMessage or GetMessage and when it is passed off through DispatchMessage. You will see the use of a method named TranslateMessage which despite its name, does not perform the modification of any messages. Instead, it creates new messages in response to certain virtual key messages and adds these to the message queue. For the programs that I present, the specifics of what it does are not important and I will not be modifying any messages in the message pump.
I do not use any of the traditional Win32 UI elements in the programs that I will be sharing (buttons, labels, text boxes, list boxes, etc.) but those elements could easily be created within the application. If I were making a framework for such controls, I would probably make classes for each one. My base class does have a CreateButton and CreateLabel method that are used for debug purposes.
This class is abstract and cannot be directly initialized. So, there first must be a derived class. The only methods that the derived class must absolutely implement are the constructor and the method GetWindowsClassName(). The constructor must accept a HINSTANCE argument and pass it to the AppWindow base class constructor. GetWindowClassName() must return a unique string. This string is going to be used for registering the window class.
To make an application that runs, all that is left to do is create a derived application window, call its Init() method (which is where it actually creates its Window) and call its message pump.
Running the application will result in a window showing a label and a button. It does not do anything yet, which is what is desired. The code samples to be posted in the future, require that there be an initialized window (which this provides). The entirety of the code can be found on GitHub.
j2i.net 