Today I was working on an application with a colleague. The application contained many dialogs, well, it was a settings related app which let the user perform and view all sort of settings on the phone. The application was medium sized with the original code very badly written. And we were supposed to clean up the code and change the look and feel of the various Dialogs used in the app. And also make sure that the same code base worked on both Standard and Professional devices, when compiled with different flags of course. We were almost through most of the things but one problem kept bothering us for a long time. One of the dialogs in the app never displayed correctly. And it was strange because it was exactly the same as other dialogs. The DialogProc of the dialog looked something like this:
BOOL CALLBACK DlgProc((HWND hDlg, UINT uMessage, WPARAM wParam, LPARAM lParam)
{
BOOL fRet = FALSE;
switch(uMessage)
{
case WM_INITDIALOG:
{
/*
Do SHInitDialog()
*/
/*
Do SHCreateMenuBar()
*/
/*
Setup controls in the dialog
*/
return TRUE;
}
break;
case WM_COMMAND:
{
/*
Handle all controls here
*/
return TRUE;
}
break;
case WM_ACTIVATE:
{
/*
Do some stuff
*/
}
break;
case WM_PAINT:
{
hdc = BeginPaint(hDlg, &ps);
EndPaint(hDlg, &ps);
}
break;
case WM_CLOSE:
{
EndDialog(hDlg, uMessage);
}
break;
}
fRet = TRUE;
return fRet;
}
Well, the code was a lot more messy than is shown here. Anyways, we sat wondering why only this dialog was not getting displayed properly. The background of the dialog was not at all drawn and the controls on the dialog appeared shabbily. We thought that a certain sequence of events caused the dialog to be displayed that way, so we tried calling the dialog from different places but the result still the same. We checked and compared the dialog properties of various dialogs with this one. They were insignificantly different but we still tried to make them exactly same, but still no luck yet. After about 2 hours I noticed the return value of the dialog proc and saw that it was always returning true no matter what. And I knew. How in the silly world can I miss such an important thing for this long! The return value of a dialog proc is a really important thing. Returning TRUE from the function means that you have handled the message and the OS may or may not take further action, mostly it wont. Returning FALSE would tell the OS that you have not handled the message and the OS would now handle the message and execute the default handling for that message. Why our dialog was not getting displayed correctly was that, we were returning TRUE for all messages, including WM_PAINT. So the OS thought that I have handled the paint message it does not need to take any action. And that is why there were problems in painting the dialog. We changed the return value to be TRUE or FALSE depending on whether we handled that message or not and it worked.