Advanced MFC Programming

Chapter 7. Common Dialog Boxes
different. For example, in the dialog’s initialization stage, message WM_INITDIALOG will be sent, if we want
to add other initialization code, we could implement it under “case WM_INITDIALOG” statement.
In MFC, this procedure is encapsulated by message mapping. We don’t have to write hook procedure,
because we can map any message to a specific member function. For example, in MFC, message
WM_INITDIALOG is always mapped to function OnInitDialog(), so we can always do our initialization work
within this member function.
When we use MFC classes to implement common dialog boxes, there is a hook function
_AfxCommDlgProc(…) behind us. We never need to know its existence. However, we use it indirectly
whenever a common dialog box is created. By looking at MFC source code, we will find that in the
constructors of common dialog boxes, the address of this function is assigned to member lpfnHook.
To make full use of MFC resource, instead of creating a new hook function, we can use
_AfxCommDlgProc(…) when calling API functions to implement common dialog boxes.
Using MFC Classes together with API Functions
When we use MFC class to create a window, the window’s handle is automatically saved in a member
variable. So we can always use the member functions to access this window. If we use API functions, no
MFC class declared variables can participate in window creating activities, so we will not have any variable
that can be used to call the member functions of MFC classes for accessing the window. This doesn’t mean
we are going to give up MFC implementation completely. Whenever possible, we want to use the member
functions of CColorDialog or CFileDialog instead of implementing everything by our own. Actually, a
window and a MFC class declared variable can be associated together after the window is created by
calling function CWnd::Attach(…). The following is the format of this function:
BOOL CWnd::Attach(HWND hWndNew);
So long as we have a valid window handle, we can attach it to a MFC class declared variable.
Obtaining Handle
When we call function ::ChooseColor(…) or ::Choosefont(…), no window handle will be returned.
The only place we can obtain dialog’s handle is in the hook function (through parameter hdlg). We can
attach this handle to a CColorDialog or CFontDialog declared variable after receiving message
WM_INITDIALOG.
Accessing Member Variable from Static or Global Function
Because a hook function is a callback function, it must be either a static or global function. Therefore,
we can not access the member variable of a class within the hook function. To let the window handle be
attached to a member variable, we must pass its address to the callback function through a message
parameter. By doing this, after receiving the message, the member variable can be accessed through a
pointer within the callback function.
Both structure CHOOSECOLOR and CHOOSEFONT have a member lCustData, which allows us to specify a
custom data that will be sent to the callback function along with WM_INITDIALOG message. The custom data
will be contained in LPARAM message parameter. So if we assign the address of a variable declared by MFC
class to member lCustData, we can receive it in the dialog box’ initialization stage and call function
CWnd:: Attach(…) to attach the window handle to this variable.
In other cases we would like to call the default hook procedure. We can store the address of the default
hook procedure in a variable, and call it within the our hook procedure as follows:
UINT CALLBACK CommonHook(HWND hDlg, UINT iMsg, UINT wParam, LONG lParam)
{
if(iMsg == WM_INITDIALOG)
{
CWnd *pDlg;
pDlg=(CWnd *)((LPCHOOSEFONT)lParam)->lCustData;
pDlg->Attach(hDlg);
194