Solved

Dialogbox (non-MFC) works fine in Debug from IDE, but is missing title and border in Release

Posted on 2004-08-25
7
461 Views
Last Modified: 2010-04-24
I call two different dialogboxes (created in Resource editor) from unmanaged C++ like so:

iRet = ::DialogBox(::GetModuleHandle("T_Calc.dll"), MAKEINTRESOURCE(IDD_DIALOG1), GetDesktopWindow(), (DLGPROC)Calculate::ToldDlgProc);

(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(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
{
      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_EDIT1,sInputData,sizeof sInputData))
                                    *sInputData = 0;

                        /* - Cancel is pressed */
                        case IDCANCEL:
                              EndDialog(hWnd, wParam);
                              return true;
                  }
                  break;
      }
 
      return false;
} // ToldDlgProc

0
Comment
Question by:scrdb
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3
7 Comments
 

Author Comment

by:scrdb
ID: 11893821
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).
0
 
LVL 1

Expert Comment

by:kahnadex
ID: 11894655
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
0
 

Author Comment

by:scrdb
ID: 11895008
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
0
Enroll in June's Course of the Month

June’s Course of the Month is now available! Experts Exchange’s Premium Members, Team Accounts, and Qualified Experts have access to a complimentary course each month as part of their membership—an extra way to sharpen your skills and increase training.

 
LVL 1

Expert Comment

by:kahnadex
ID: 11895225
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
0
 
LVL 1

Accepted Solution

by:
kahnadex earned 500 total points
ID: 11895295
(Here's an example)

BOOL CALLBACK Calculate::ToldDlgProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
{
     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_EDIT1,sInputData,sizeof sInputData))
                              *sInputData = 0;

                    /* - Cancel is pressed */
                    case IDCANCEL:
                         EndDialog(hWnd, wParam);
                         return TRUE;
               }
               break;
     }
 
     return DefDlgProc(hWnd, Msg, wParam, lParam);
} // ToldDlgProc
0
 

Author Comment

by:scrdb
ID: 11897090
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
0
 

Author Comment

by:scrdb
ID: 11933154
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).

0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

The following diagram presents a diamond class hierarchy: As depicted, diamond inheritance denotes when two classes (e.g., CDerived1 and CDerived2), separately extending a common base class (e.g., CBase), are sub classed simultaneously by a fourt…
In Easy String Encryption Using CryptoAPI in C++ (http://www.experts-exchange.com/viewArticle.jsp?aid=1193) I described how to encrypt text and recommended that the encrypted text be stored as a series of hexadecimal digits -- because cyphertext may…
Monitoring a network: how to monitor network services and why? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the philosophy behind service monitoring and why a handshake validation is critical in network monitoring. Software utilized …
Add bar graphs to Access queries using Unicode block characters. Graphs appear on every record in the color you want. Give life to numbers. Hopes this gives you ideas on visualizing your data in new ways ~ Create a calculated field in a query: …

718 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question