Chapter 2 transformation of a simplest window Program
I know, there may be many friends on the "Hello, world!" Chapter !" The ATL version does not agree, because it is not an ATL Program-after all, it only has a ccommodule. However, I still want to say that it still has almost all the components of an ATL GUI program: entry, initialization, program body, uninstallation ......
"Wait !" Maybe you will suddenly interrupt me, "-- what about the registration window class and message loop ?"
Of course, this is also necessary for a complete GUI program.
Nonsense
It is not clear whether you have prepared for the content of this chapter, because we are going to be real. However, considering that there may be a considerable number of friends who are familiar with MFC but are not familiar with the basic principles and procedures of Win32 GUI, therefore, Li Ma specially prepared the content of this section for you. SDK fans can skip this section, if you think Li Ma is a little slow.
Then, I should start with a standard Win32 SDK program:
//////////////////////////////////////// //////////////////////////////////
// The source code of the atl gui Program Design
// Chapter 2 transformation of a simplest window Program
// Project name: hellosdk
// Author: Li Ma
// Http://www.titilima.cn
//////////////////////////////////////// //////////////////////////////////# Include <windows. h>
# Include <tchar. h> Lresult callback hellowndproc (hwnd, uint umsg, wparam, lparam)
{
Switch (umsg)
{
Case wm_destroy:
{
Postquitmessage (0 );
}
Break;
Case wm_paint:
{
HDC;
Paintstruct pS; HDC = beginpaint (hwnd, & PS );
Drawtext (HDC, _ T ("Hello, SDK! "),-1, & PS. rcpaint, dt_center | dt_vcenter | dt_singleline );
Endpaint (hwnd, & PS );
}
Break;
Default:
Return defwindowproc (hwnd, umsg, wparam, lparam );
}
Return 0;
} Bool initapplication (hinstance)
{
Wndclass WC;
WC. cbclsextra = 0;
WC. cbwndextra = 0;
WC. hbrbackground = (hbrush) getstockobject (white_brush );
WC. hcursor = loadcursor (null, idc_arrow );
WC. hicon = loadicon (null, idi_application );
WC. hinstance = hinstance;
WC. lpfnwndproc = hellowndproc;
WC. lpszclassname = _ T ("hellosdk ");
WC. lpszmenuname = NULL;
WC. Style = cs_hredraw | cs_vredraw; Return registerclass (& WC );
} Int winapi _ twinmain (hinstance, hinstance hprevinstance, lptstr lpcmdline, int nshowcmd)
{
// Register the window class
Initapplication (hinstance ); // Create a window
Hwnd = createwindow (_ T ("hellosdk"), _ T ("Hello SDK"), ws_overlappedwindow, cw_usedefault, cw_usedefault,
Cw_usedefault, cw_usedefault, null, null, hinstance, null );
Showwindow (hwnd, nshowcmd );
Updatewindow (hwnd ); // Message loop
MSG;
While (getmessage (& MSG, null, 0, 0 ))
{
Translatemessage (& MSG );
Dispatchmessage (& MSG );
} return msg.wParam;
}
|
I wonder if you think this code is too long? In fact, this program has reflected all the processes for running the Win32 GUI Program (please note that I will not explain the code in detail, because I have already assumed that you have understood the necessary details of the Code's specific behavior. If this is not the case, please refer to the relevant books or msdn ):
- Register the window class. In this program, the initapplication function completes this job. The concept of window class is similar to that of OO (Object-Oriented). All windows you can see in windows are an instance of a specific window class. However, a window class is not a class in any OOP language-it does not include generic attributes and methods (called member variables and member functions in C ++ ), but attributes and responses. This difference may be confusing for you. I will introduce it in detail in the next chapter-because the encapsulation class of windows in ATL fully reflects this point.
- Create a window. In the general SDK code, the code is encapsulated in a function named initinstance. This Code generally creates a window and displays it.
- Message loop. Windows is a message-based operating system, and the communication between windows is mainly completed by Windows messages. The message loop in the program extracts various messages from the message queue in the UI thread of the Program for processing (if necessary) it is then distributed to the main window (or the target window) of each message ).
It should be noted that hellowndproc is a function defined by us. We need to use it to control our specific response to specific window messages. You only need to assign the function address (that is, the function name) to the wndclass: lpfnwndproc member before registering the window class. We do not need to call this function. It is called by windows when the window receives the window message. In this callback function, our processing is as follows:
- Wm_destroy. When the window is destroyed, the window receives the message. Here, we will call postquitmessage to send a wm_quit message to the Message Queue of the current UI thread. After receiving the message, getmessage returns false, which ends the message loop, winmain is over.
- Wm_paint. When the window needs to be drawn, the window will receive this message. Here, we simply draw a line of text "Hello, SDK!" in the middle of the window !".
- Other messages. We don't care about these messages, so we will handle them with the default Window Process defwindowproc.
This Code seems to be lengthy, but it is actually very well organized. You can compare it with the ATL version of this program based on its and my explanations above.
ATL and other similar products
When writing this book, I always hope that every time I can use code that makes you less unfamiliar to guide you step by step. Think twice, for "hello, ATL !" I decided to display its winmain to you first:
Int winapi _ twinmain (hinstance, hinstance hprevinstance, lptstr lpcmdline, int nshowcmd)
{
_ Module. INIT (null, hinstance );// Create a window
Chelloatlwnd WND;
WND. Create (null, chelloatlwnd: rcdefault, _ T ("Hello ATL "));
WND. showwindow (nshowcmd );
WND. updatewindow (); // Message loop
MSG;
While (getmessage (& MSG, null, 0, 0 ))
{
Translatemessage (& MSG );
Dispatchmessage (& MSG );
} _Module.Term();
return msg.wParam;
}
|
OK, the _ module introduced in the previous chapter is now in front of you -- but there are still no special changes, and it is still the familiar init and term. In addition, like "mountain or mountain", the message loop is still the message loop. Of course, you must have also discovered the few changes: What is chelloatlwnd? Before I show you its code, you may make the following conjecture:
- This is a C ++ class, which encapsulates the Win32 window class.
- This class encapsulates API functions for most window operations, such as createwindow, showwindow, and updatewindow.
- The registration of window classes may also be completed in the C ++ class.
Okay, stop. That's enough. Let's get rid of the mysterious veil of chelloatlwnd. Hurry up.
class CHelloATLWnd : public CWindowImpl< CHelloATLWnd, CWindow, CWinTraits< WS_OVERLAPPEDWINDOW > >
{
public:
CHelloATLWnd()
{
CWndClassInfo& wci = GetWndClassInfo();
wci.m_bSystemCursor = TRUE;
wci.m_lpszCursorID = IDC_ARROW;
wci.m_wc.hbrBackground = (HBRUSH)GetStockObject( WHITE_BRUSH );
wci.m_wc.hIcon = LoadIcon( NULL, IDI_APPLICATION );
}
public:
DECLARE_WND_CLASS( _T("HelloATL") )
public:
BEGIN_MSG_MAP( CHelloATLWnd )
MESSAGE_HANDLER( WM_DESTROY, OnDestroy )
MESSAGE_HANDLER( WM_PAINT, OnPaint )
END_MSG_MAP()
public:
LRESULT OnDestroy( UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& hHandled )
{
::PostQuitMessage( 0 );
return 0;
}
LRESULT OnPaint( UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& hHandled )
{
HDC hdc;
PAINTSTRUCT ps; hdc = BeginPaint( &ps );
DrawText( hdc, _T("Hello, ATL!"), -1, &ps.rcPaint, DT_CENTER | DT_VCENTER | DT_SINGLELINE );
EndPaint( &ps );
return 0;
}
};
|
Conjecture, or conjecture!
In this chapter, I will not explain the details of this class. Instead, I will continue to guess. Because there are so many things to be explained in this class that I must open a separate chapter for it.
- The registration of window classes is completed by the constructor of the C ++ class and the declare_wnd_class macro.
- For the begin_msg_map and end_msg_map sections, it should be easier for friends who have used MFC. Yes, this macro can be counted as the message ing of ATL, where message_handler acts as the message shunt and distributes various window messages to various processing functions.
- The style specified during window creation seems to be related to the template parameter cwintraits.
Of course, in addition to these guesses, you may also have the following questions:
- What is cwindowimpl, cwindow, and cwintraits?
- When is the window class registered?
- How is message shunt implemented?
Maybe you have more questions, so let me leave them in the next chapter and solve them. If you can't wait, the atlwin. H code will tell you everything.
Supplement ccommodule
This book is mainly intended for ATL 3.0/Visual C ++ 6.0, So I neglected to study ccommodule. I would like to thank Mr. Li for his suggestion that ccommodule is no longer recommended in ATL 7.0. So I excerpted the relevant chapters in msdn and used them as examples.
Ccommodule replacement class
Early versions of ATL use ccommodule. In ATL 7.0, the ccommodule function is replaced by several classes:
- Catlbasemodule contains the information required by most ATL applications. Hinstance that contains modules and resource instances.
- Catlcommodule contains the information required by the COM class in ATL.
- Catlwinmodule contains the information required by the window class in ATL.
- Catldebuginterfacesmodule contains interface debugging support.
- Catlmodule the following catlmodule-Derived classes are customized to contain the information required in a specific application type. Most of the members of these classes can be rewritten:
Catldllmodulet is used in DLL applications. Provides code for standard export.
Catlexemodulet is used in the EXE application. Provide the Code required by exe.
Catlservicemodulet provides support for creating Windows NT and Windows 2000 services.
Ccommodule is still available for backward compatibility.
Reasons for ccommodule Function Distribution
The functions of ccommodule are distributed to several new classes for the following reasons:
- Make the functions in ccommodule segmented in a granular manner.
Support for com, window, interface debugging, and application-specific (DLL or EXE) functions is now in different classes.
- Global instances are automatically declared for each of these modules.
The global instance of the required module class is linked to the project.
- Eliminates the need to call the init and term methods.
The init and term methods have been moved to the constructor and destructor of the module class. You do not need to call init and term.
However, for the sake of code compatibility and wtl content, this series of subsequent articles will still use the ccommodule in ATL 3.0.
Click here to download the supporting code in this Chapter
