Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.
One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.
Dialogbox (non-MFC) works fine in Debug from IDE, but is missing title and border in Release
I call two different dialogboxes (created in Resource editor) from unmanaged C++ like so:
iRet = ::DialogBox(::GetModuleHan
(The call to the other dialogbox is exactly the same, but the resource name is IDD_DIALOG2)
When I run in Debug mode (i.e. press F5), everything works as it should. However, when I compile the Release project and run the resulting Setup, the two dialogboxes show only the controls in the dialogbox. The background is transparent, and the title bar and border are missing. They still work (I can enter info into an edit box, and press the OK and Cancel buttons), but they're very hard to see.
Anyone have any ideas? I'm talking to an MS tech support person about this, but he's currently stumped.
The callback function for the call above looks like:
bool CALLBACK Calculate::ToldDlgProc(HWN
{
switch(Msg)
{
/* - Initialize dialog box */
case WM_INITDIALOG:
/* - Set the dialog box title */
::SetWindowText(hWnd, title);
/* - Default the input text box */
::SetDlgItemText(hWnd, IDC_EDIT1, sInputData);
/* - Set the prompt text */
::SetDlgItemText(hWnd, IDC_EDIT2, prompt);
return true;
case WM_COMMAND:
switch(LOWORD(wParam))
{
/* - OK is pressed */
case IDOK:
/* - If there is nothing in the text box, blank out global variable */
if (!GetDlgItemText(hWnd,IDC_
*sInputData = 0;
/* - Cancel is pressed */
case IDCANCEL:
EndDialog(hWnd, wParam);
return true;
}
break;
}
return false;
} // ToldDlgProc
iRet = ::DialogBox(::GetModuleHan
(The call to the other dialogbox is exactly the same, but the resource name is IDD_DIALOG2)
When I run in Debug mode (i.e. press F5), everything works as it should. However, when I compile the Release project and run the resulting Setup, the two dialogboxes show only the controls in the dialogbox. The background is transparent, and the title bar and border are missing. They still work (I can enter info into an edit box, and press the OK and Cancel buttons), but they're very hard to see.
Anyone have any ideas? I'm talking to an MS tech support person about this, but he's currently stumped.
The callback function for the call above looks like:
bool CALLBACK Calculate::ToldDlgProc(HWN
{
switch(Msg)
{
/* - Initialize dialog box */
case WM_INITDIALOG:
/* - Set the dialog box title */
::SetWindowText(hWnd, title);
/* - Default the input text box */
::SetDlgItemText(hWnd, IDC_EDIT1, sInputData);
/* - Set the prompt text */
::SetDlgItemText(hWnd, IDC_EDIT2, prompt);
return true;
case WM_COMMAND:
switch(LOWORD(wParam))
{
/* - OK is pressed */
case IDOK:
/* - If there is nothing in the text box, blank out global variable */
if (!GetDlgItemText(hWnd,IDC_
*sInputData = 0;
/* - Cancel is pressed */
case IDCANCEL:
EndDialog(hWnd, wParam);
return true;
}
break;
}
return false;
} // ToldDlgProc
Asked:
-
4
3
1 Solution
I'm developing in Visual Studio 2003. The main .exe is in VB, that's why I have to pass the T_Calc.dll handle to the DialogBox function (that's where the resources are defined).
Well, this sounds like a weird problem.. Maybe I can help you. What exactly is in T_Calc.dll? It has your dialog resources obviously, but what else does it have? Is it compiled in release mode when you are in debug mode?
I would have to say maybe there is a problem with the settings on building T_Calc.dll. If it works great for your main executable in debug mode but not in release, perhaps try recompiling T_calc.dll in release mode
Just throwing some ideas out there, keep me updated
I would have to say maybe there is a problem with the settings on building T_Calc.dll. If it works great for your main executable in debug mode but not in release, perhaps try recompiling T_calc.dll in release mode
Just throwing some ideas out there, keep me updated
kahnadex,
Thank you for your response.
T_Calc.dll contains all my managed and unmanaged C++ code, in addition to the resources. When I test in Debug mode, I select Debug from the Solution configuration drop-down on the Standard toolbar, then rebuild everything. When I go to create an MSI setup, I select the Release configuration and rebuild everything.
It almost seems to be a "repaint" kind of problem, but I've noticed that not only is the title bar not displaying, it's not set to text that it is when in Debug mode (I can see its entry on the Windows taskbar). The taskbar item shows "Inputs", which is what it's set to in the Resource editor. I overwrite it in the initialization of the dialog box (see code above). When in Debug, the taskbar item correctly shows the window title.
Stu
Thank you for your response.
T_Calc.dll contains all my managed and unmanaged C++ code, in addition to the resources. When I test in Debug mode, I select Debug from the Solution configuration drop-down on the Standard toolbar, then rebuild everything. When I go to create an MSI setup, I select the Release configuration and rebuild everything.
It almost seems to be a "repaint" kind of problem, but I've noticed that not only is the title bar not displaying, it's not set to text that it is when in Debug mode (I can see its entry on the Windows taskbar). The taskbar item shows "Inputs", which is what it's set to in the Resource editor. I overwrite it in the initialization of the dialog box (see code above). When in Debug, the taskbar item correctly shows the window title.
Stu
Hi Stu
Here's something you can try
i would change the return value to a BOOL instead of a true bool and return TRUE when you handle the dialogs events. then instead of return false, return DefDlgProc(hWnd, Msg, wParam, lParam)
Try that out and see what happens
Here's something you can try
i would change the return value to a BOOL instead of a true bool and return TRUE when you handle the dialogs events. then instead of return false, return DefDlgProc(hWnd, Msg, wParam, lParam)
Try that out and see what happens
(Here's an example)
BOOL CALLBACK Calculate::ToldDlgProc(HWN
{
switch(Msg){
/* - Initialize dialog box */
case WM_INITDIALOG:
/* - Set the dialog box title */
::SetWindowText(hWnd, title);
/* - Default the input text box */
::SetDlgItemText(hWnd, IDC_EDIT1, sInputData);
/* - Set the prompt text */
::SetDlgItemText(hWnd, IDC_EDIT2, prompt);
return true;
case WM_COMMAND:
switch(LOWORD(wParam)){
/* - OK is pressed */
case IDOK:
/* - If there is nothing in the text box, blank out global variable */
if (!GetDlgItemText(hWnd,IDC_
*sInputData = 0;
/* - Cancel is pressed */
case IDCANCEL:
EndDialog(hWnd, wParam);
return TRUE;
}
break;
}
return DefDlgProc(hWnd, Msg, wParam, lParam);
} // ToldDlgProc
BOOL CALLBACK Calculate::ToldDlgProc(HWN
{
switch(Msg){
/* - Initialize dialog box */
case WM_INITDIALOG:
/* - Set the dialog box title */
::SetWindowText(hWnd, title);
/* - Default the input text box */
::SetDlgItemText(hWnd, IDC_EDIT1, sInputData);
/* - Set the prompt text */
::SetDlgItemText(hWnd, IDC_EDIT2, prompt);
return true;
case WM_COMMAND:
switch(LOWORD(wParam)){
/* - OK is pressed */
case IDOK:
/* - If there is nothing in the text box, blank out global variable */
if (!GetDlgItemText(hWnd,IDC_
*sInputData = 0;
/* - Cancel is pressed */
case IDCANCEL:
EndDialog(hWnd, wParam);
return TRUE;
}
break;
}
return DefDlgProc(hWnd, Msg, wParam, lParam);
} // ToldDlgProc
kahnadex,
I was getting exceptions when I used the DefDlgProc(...) as a return, but when I replaced that with FALSE (as well as changing the return to BOOL), it began to work.
Thanks very much for your suggestion.
Stu
I was getting exceptions when I used the DefDlgProc(...) as a return, but when I replaced that with FALSE (as well as changing the return to BOOL), it began to work.
Thanks very much for your suggestion.
Stu
Following is the text of a message I received from the MS support team regarding the fix of the DialogBox display problem (I took his advice and changed the DialogProc return value from a BOOL to an INT_PTR):
That fixing the return type of your DialogProc makes perfect sense. Having the wrong function signature can cause all sorts of hard to track down problems. Actually though, your DialogProc should actually be an INT_PTR, not a BOOL. The definition in winuser.h is:
typedef INT_PTR (CALLBACK* DLGPROC)(HWND, UINT, WPARAM, LPARAM);
The compiler should throw a warning if you get this wrong, unless you cast the warning away when you call DialogBox (the Visual C++ App Wizard gets this wrong as well, and then “fixes” it by casting the warning away. If your function signature is correct then you won’t have to cast it to a DLGPROC).
The reason that defining your return type as bool caused trouble but BOOL didn’t is that a bool is a 1 byte value and BOOL is 4 bytes. INT_PTR is also 4 bytes (on Win32), and so the return types are compatible.
I suspect that this worked for you in your debug build because the compiler zeroed out the unused 3 bytes. In your retail build the compiler left whatever happened to be in the unused 3 bytes as it was. If those bytes are non-zero, then the INT_PTR value will be non-zero, and DefDlgProc will think that your DialogProc handled painting messages that it wasn’t handling (since its one-byte false was actually a four-byte TRUE).
That fixing the return type of your DialogProc makes perfect sense. Having the wrong function signature can cause all sorts of hard to track down problems. Actually though, your DialogProc should actually be an INT_PTR, not a BOOL. The definition in winuser.h is:
typedef INT_PTR (CALLBACK* DLGPROC)(HWND, UINT, WPARAM, LPARAM);
The compiler should throw a warning if you get this wrong, unless you cast the warning away when you call DialogBox (the Visual C++ App Wizard gets this wrong as well, and then “fixes” it by casting the warning away. If your function signature is correct then you won’t have to cast it to a DLGPROC).
The reason that defining your return type as bool caused trouble but BOOL didn’t is that a bool is a 1 byte value and BOOL is 4 bytes. INT_PTR is also 4 bytes (on Win32), and so the return types are compatible.
I suspect that this worked for you in your debug build because the compiler zeroed out the unused 3 bytes. In your retail build the compiler left whatever happened to be in the unused 3 bytes as it was. If those bytes are non-zero, then the INT_PTR value will be non-zero, and DefDlgProc will think that your DialogProc handled painting messages that it wasn’t handling (since its one-byte false was actually a four-byte TRUE).
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
Join & Write a Comment Already a member? Login.
Featured Post
Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.
One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.
Tackle projects and never again get stuck behind a technical roadblock.
Join Now