Link to home
Start Free TrialLog in
Avatar of dmaroff
dmaroff

asked on

Hiding a dialog box

Im creating a Dialog box from WinMain and when Im inside the dialog box I cant seem to get it to hide itself.

Im using the ShowWindow() function and for some reason it wont hide itself.  However it will minimize itself.  The only wierd thing about my program is Im using GetDesktopWindow() as my handle to the dialog box window.  Im doing this cause I dont want to have to register a main window, I only need a dialog box window for this program.

Here is my WinMain:
---------------------------------------
HWND hMainWnd;


int APIENTRY WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance,
                      LPSTR lpszCmdParam, int nCmdShow )
{
  WSADATA ws;
  lpszCommand = lpszCmdParam;

  WSAStartup(MAKEWORD(1, 1) ,&ws);
  hMainWnd = GetDesktopWindow();

  DialogBox(hInstance, MAKEINTRESOURCE  
           (IDD_DIALOG), hMainWnd,
           (DLGPROC) DialogFunc);
      
  return 0;
}
--------------------------------------
Inside the dialog box Im uing a procedure like this:

case WM_INITDIALOG:
   if(x) {
     ShowWindow(dlgHwnd, SW_HIDE);
   }
   break;
--------------------------------------
So depending on x, which is a coomand like argument, sometimes the box shows and sometimes not. But yet it always shows.

Anyone know why?

Thanks,
-Dan
Avatar of pjknibbs
pjknibbs

WM_INITDIALOG is sent to the dialog box *before it is displayed*. Therefore, at this time the dialog window does not exist, so the ShowWindow() call cannot possibly work. In order to do what you want you'll have to make your dialog window post a message to itself in WM_INITDIALOG, and then hide it when you receive that message; unfortunately this will result in a brief "flash" of your dialog onscreen. I don't think there's any way round this without converting your dialog into a normal window, because there are too many details hidden inside the DialogBox() call which can't be changed.
Avatar of dmaroff

ASKER

Yea, I tried having it send itself a message from within WM_INITDIALOG.  But Im afraid thats didn't work either.  I going to try creating a modeless dialog box instead and have WinMain (since it wont block) hide the dialog box after calling the CreateDialog() function.  I guess I'll see if that works.

My only question is, how would I have WinMain not return since it wont block after the CreateDialog() call?  When I exit the dialog is when I want WinMain to return.

Thanks,
-Dan  
ASKER CERTIFIED SOLUTION
Avatar of pjknibbs
pjknibbs

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of dmaroff

ASKER

Your code works very well, but how does the TranslateMessage(&msg) & DispatchMessage(&msg)

functions work without a WinProc() to handle the messages?  Were do the messages come from?  What window?  Can you explain, I find it kind of interesting how it works.

The only bad thing I noticed is that now I can't use the TAB key to switch between text controls anymore on the dialog box.  Im guessing this is because when I added your code, the GetMessage() in WinMain() is handling the keyboard now, instead of the dialog box.  I tested the dialog box in the resource editor so I know it must be something with messages.

How would I fix this?

Thanks a lot for the help,
-Dan
Avatar of dmaroff

ASKER

Also it says up top that I have you 5 points, just check to make sure I did give you the 50 points.

-Dan
GetMessage() retrieves messages for all windows in the current thread. Since a dialog box is just a window with some wrapper code, messages for it get retrieved by GetMessage() and then processed by Translate and Dispatch. The messages actually "come from" Windows itself.

To re-instate the keyboard shortcuts in the dialog box you need to do this:

while (GetMessage(&msg, NULL, 0, 0))
{
    if (!IsDialogMessage(hDlg, &msg))
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
}

where hDlg is the window handle of your dialog box.

As for the 5 points, that's what it costs to read a PAQ (Previously Asked Question) if you weren't one of those who originally contributed to it...it's always a tenth of the original value of the question.
Avatar of dmaroff

ASKER

Works great, but if I didn't have your GetMessage() code in WinMain, the dialogbox would still receive and handle messages from Windows.  So isn't this code kind of getting in the way of the dialog box's original message handling?  Or am I thinking of a modal dialog box?  Im just trying to figure out how this all works.

So I can give you the points, answer the question and I'll give you the rest of the points.

Thanks a lot,
you really help me.
-Dan
Not true! If you create a dialog using CreateDialog() (i.e. a modeless dialog) you *must* use a message loop of your own, or else the dialog will not get any messages and won't work. Try commenting out the message loop and see what happens! The reason DialogBox() does not need a message loop is because there's a message loop embedded within the API call--this silently handles all the messages for the modal dialog until you call EndDialog().
Avatar of dmaroff

ASKER

Ok I understand now.  But lets say I created a window using CreateWindow() and had called CreateDialog() twice for two seperate dialog templates, would I need 3 message loops then?  How would the message loop destinguish one window from the other?  Im just curious how that would work.

Thanks for all your help,
-Dan
The second parameter of GetMessage() specifies which window to retrieve messages for. If this parameter is NULL, as in my example, the function will retrieve messages for *all* windows created by the current thread--therefore, you only need one message loop per thread. Unless you want to get into multithreading, which is an entirely different topic, you only need one message loop per application.
Avatar of dmaroff

ASKER

Ok, well thanks for the help I really appreciate you responding back to me.  Sometimes its nicer to have someone explain it than reading 20 different books.

-Dan