Fancy Custom MessageBox

Introduction

One of the most used Windows API functions is MessageBox. You easily can set its contents (caption, text, and buttons) and behavior (application, task, or system modal) but it’s not flexible enough to allow changing, for example, its appearance. Of course, you can make your own dialog box, based on a dialog resource template, but this is not always the handiest choice. This article shows a simple method for customizing a message box’s appearance, but not only the appearance.

Here is an example of message box with a custom background (it can be your company logo as well) and changed text color.

A First Try

After searching SDK headers, some people could be tempted to handle the WM_CTLCOLORMSGBOX message (not documented but defined in WINUSER.H). It seems to be destined, like the other WM_CTLCOLORxxx messages (WM_CTLCOLORSTATIC, WM_CTLCOLOREDIT, and so forth), to be sent to the parent window when a message box is about to be drawn. Then, it’s just “a walk in the park” to change the message box text color, backround color, and so on.

That’s no use! You can try handling WM_CTLCOLORMSGBOX as in the following example and see that the WM_CTLCOLORMSGBOX message is never sent.

BOOL CALLBACK DialogProc(HWND hWnd, UINT uMsg, WPARAM wParam,
                         LPARAM lParam)
{
   switch(uMsg)
   {
      //...
      HANDLE_MSG(hWnd, WM_CTLCOLORMSGBOX, Dlg_OnCtlColorMsgBox);
   }
   return FALSE;
}

HBRUSH Dlg_OnCtlColorMsgBox(HWND hWnd, HDC hdc, HWND hWndChild,
                            int type)
{
   HBRUSH hbr = NULL;
   // Just for testing WM_CTLCOLORMSGBOX message.
   if(CTLCOLOR_MSGBOX == type)
   {
      // hbr = ... get a valid brush handle to return ...
      // But it NEVER enters here!!!
   }
   return hbr;
}

What Can be Done?

One idea is to trap the dialog box creation to subclass it, and then use the application-defined window procedure to handle messages that allow changing the appearance like in any other dialog window procedure. For that, you can use a CBT (computer-based training) hook.

CbtHookProc: the CBT Hook Procedure

Here is the implementation of the hook procedure:

LRESULT CALLBACK CbtHookProc(int nCode, WPARAM wParam,
                             LPARAM lParam)
{
   if(nCode < 0)
   {
      return ::CallNextHookEx(cmbv.hHook, nCode, wParam, lParam);
   }
   switch(nCode)
   {
   case HCBT_CREATEWND:    // a window is about to be created
      {
         LPCBT_CREATEWND lpCbtCreate = (LPCBT_CREATEWND)lParam;
         if(WC_DIALOG == lpCbtCreate->lpcs->lpszClass)
         {
            // WC_DIALOG is the class name of message box but it
            // has not yet had a window procedure set.
            // So keep in mind the handle to sublass it later when
            // its first child is about to be created.
            cmbv.hWnd = (HWND)wParam;
         }
         else
         {
            if((NULL == cmbv.lpMsgBoxProc) && (NULL != cmbv.hWnd))
            {
               // subclass the dialog
               cmbv.lpMsgBoxProc =
                  (WNDPROC)::SetWindowLong(cmbv.hWnd, GWL_WNDPROC,
                     (LONG)CustomMessageBoxProc);
            }
         }
      }
      break;
   case HCBT_DESTROYWND:    // a window is about to be destroyed
      {
         if(cmbv.hWnd == (HWND)wParam)    // it's our messge box
         {
            // so set back its default procedure
            ::SetWindowLong(cmbv.hWnd, GWL_WNDPROC,
                            (LONG)cmbv.lpMsgBoxProc);
         }
      }
   }
   return 0;
}

You can observe a little trick in the code above: The dialog box is not subclassed when its own creation is signaled. That’s because, at that time, it has not yet associated a procedure. You know that any message box contains at least one control, so you subclass it a little bit later, when its first child is about to be created.

More by Author

Must Read