These are some tricks I've discovered along the way when I've been using
dialog boxes both in non-dialog based apps and in dialog-based apps. Some of the
might seem naive but yet are pretty handy. I thought I'd share some of these
tricks with you.
Starting a modal dialog hidden
You often hear people complain that despite putting a
OnInitDialog their modal dialog still starts up in a shown state. The
problem here is that when
CDialog::OnInitDialog() finishes it will call
ShowWindow(SW_SHOW). Thus your dialog box is again made visisble. But then as, is
to be expected, people have worked around this. Here is what you need to do.
BOOL member to your dialog class and call it something, say
Now in your dialog constructor set
visible = false;
Now you need to override
WM_WINDOWPOSCHANGING. You might have to change your
message filtering options to have this message show up in the Class Wizard.
void CTest_deleteDlg::OnWindowPosChanging(WINDOWPOS FAR* lpwndpos)
lpwndpos->flags &= ~SWP_SHOWWINDOW;
That's it. Now your modal dialog actually starts up in a hidden state. And
when you want to make it visible this is what you need to do.
visible = true;
Full screen dialogs
Sometimes you might feel the need to make a full screen dialog - means a
dialog that fills up the entire monitor. Well it's rather easy to achieve this.
You need to remove the caption and the border which we do by removing the
WS_CAPTION and the
WS_BORDER styles. Then we call
HWND_TOPMOST and resize the dialog to fill
up the entire screen. Just put the following code into your
int cx, cy;
HDC dc = ::GetDC(NULL);
cx = GetDeviceCaps(dc,HORZRES) +
cy = GetDeviceCaps(dc,VERTRES) +
GetWindowLong(m_hWnd, GWL_STYLE) &
(~(WS_CAPTION | WS_BORDER)));
How to steal focus on 2K/XP
I bet that sometimes you long for the old days when a simple
brought your dialog into focus. Sigh! Now with 2K/XP things have sorta changed
so that if you try a simple
SetForegroundWindow you end up flashing
the taskbar icon a few times (I never counted but something tells me it flashes
thrice). Not exactly what you wanted to do, eh? Luckily there are ways to bring
your dialog into the foreground.
The trick is to use
AttachThreadInput to attach the thread that
owns the current foreground window to our thread, then call
SetForegroundWindow and then detach the attached thread, again using
AttachThreadInput. Cool, huh?
Making your dialog stay on top
Haven't you seen programs which have an "always-stay-on-top" option? Well the
unbelievable thing is that you can make your dialog stay on top with just one
line of code. Simply put the following line in your dialog class's
Basically what we are doing is to use the
SetWindowPos function to change the
Z-order of our dialog window. We make our dialog stay on top of all other
windows by moving it to the top of the Z-order. Now even when you activate some
other window, our window will stay on top. But I'd advise you to make sure you
know exactly what you are doing when you do this, for it might annoy people if
they can't get your window out of the way when they want to do that.
Expanding and Contracting your dialog boxes
I bet you have seen programs with dialog boxes that start off at one size.
They will have a button called "expanded view" or maybe something called
"advanced" and when you click on that button the dialog box expands beautifully
revealing some so-far hidden child controls. They might also have some button
called "hide details", and when you click on that it will contract back to the
original smaller size hiding the extra controls that were revealed on expansion.
This can be easily achieved using
SetWindowPos, which as you can see is quite an
Assume that you have two buttons, "MakeSmall" and "Expand". Then this is what
you need to put in their click-handler functions. Of course, you need to replace
cy parameters with your own values.
And also remember to put a call to
OnMakeSmall() in your dialog's
OnInitDialog() function so that your dialog window starts off in the contracted
size. On the contrary you may start it off expanded with a call to
OnInitDialog(). Sometimes you want to use the same button, changing the
button caption accordingly and using a boolean flag to determine when to expand
and when to contract.
By the way here is an additional tip from Thomas Freudenberg. It's
regarding the fact that even after contraction, the hidden controls are still
accesible via the keyboard, thus you might want to disable those controls using
EnableWindow. I'd like to thank Thomas for this suggestion:
You have missed something regarding "Expanding and Contracting your dialog
boxes". It seems as you prefer using the mouse than use the keyboard (You're a
so-called Mausschubser (German for mouse hustler or so)) If a dialog is
contracted, you can still use the tab key to go to controls which are outside
the dialog. I suggest to call
EnableWindow (fExtracted) for all appropriate
Getting your dialog box into the desktop
Sometimes the user might move the dialog box around screen till it is partly
outside the desktop. And you might want to bring the dialog box back into
full view. There might also be a a situation where you did the development on a
higher resolution and on your machine it comes up nice and full, but the final
user might be using a lower screen resolution and thus part of the dialog will
be out of the screen. Again you'd really want to make sure the dialog box is
fully visible. Well, believe it or not, this can be accomplished with just one
line of code.
Smooth eh? Remember that this message only works for top level dialog boxes
and will not work for child dialogs.
Adding minimize/maximize buttons to your dialog box
If you want to do this at design time, all you need to do is to set the
properties accordingly. But if for some reason you need to do this at run-time
then this is what you need to do. Override
OnCreate() and add this code to it.
Please note that putting this code in
OnInitDialog() has a weird side-effect.
The buttons do get shown, both maximize and minimize; but they are dummy,
meaning they don't function correctly. My guess is that
OnInitDialog() is too
late a place to change the style of the dialog.
int CTest_deleteDlg::OnCreate(LPCREATESTRUCT lpCreateStruct)
if (CDialog::OnCreate(lpCreateStruct) == -1)
WS_MINIMIZEBOX | WS_MAXIMIZEBOX);
Also note than
lpCreateStruct is only a copy of the original
passed. Thus changing the style bits there has no effect. And for some puzzling
(at least to me) reasons,
PreCreateWindow never gets called for a modal dialog
and thus we can't change the style bits there too, as we might do for a view
window or a frame window.
Changing the mouse cursor - from Andrew Peace
Well, I'd like to thank Andrew Peace for this suggestion. Sometimes you might
feel a need to change the default mouse cursor in a dialog. What you need to do
OnSetCursor, set a new cursor and then return without calling the
base class function as show below. I had tried this and it failed because I kept
calling the base class. Thanks again to Andrew Peace for pointing me in the
BOOL CTest_deleteDlg::OnSetCursor(CWnd* pWnd, UINT nHitTest, UINT message)
Changing a dialog's background and control text color
There is an often over-looked
CWinApp member function,
allows us to do just this. The function takes two
COLORREFs as its arguments.
COLORREF is the dialog's background color. The second
COLORREF will be
the color for static, check and radio controls. It will not affect edit and
button controls. All dialog boxes and message boxes that are brought up by
the application will globally use these colors. Put this code in your
InitInstance(). Remember to call the function just before you
This function is now obsolete! It may not even work! I'll update this tip
with the correct method in the next update!
Removing the task bar icon of your dialog based App
Sometimes you might want to create stealth dialog applications for whatever
reasons. Well they won't be stealth in the proper sense since the dialog will be
visible. But lets assume you don't want them to have taskbar icons for whatever
reasons. Here is what you do to achieve this. We first create an invisible top
level frame window. Here is the code to put into your
CFrameWnd *abc=new CFrameWnd();
m_pMainWnd = &dlg;
int nResponse = dlg.DoModal();
if (nResponse == IDOK)
else if (nResponse == IDCANCEL)
Now we need to modify the dialog window's style. So put this code in your
OnInitDialog. We need to remove the
Context sensitive help - P J Arends
This tip from Pete Arends shows you how to get context sensitive help in your
dialog boxes. The first thing you need to do is to make sure that the dialog box
has the question mark on it's title bar. For that you need to do this in the
OnInitDialog as shown below.
OnHelpInfo(...) can get called in two different situations. The first
situation is when the user presses the F1 key. This should normally bring up the
main help window for the dialog. The other situation is when the user clicks on
the question mark and then clicks on an individual control in the dialog.
Alternatively the user might also right click a control and selects the "What's
this?" option from the popup menu. Of course you'll have to handle popping up of
the menu yourself. Thus we'll need to handle these two cases as shown below.
BOOL HelpDialog::OnHelpInfo(HELPINFO* pHelpInfo)
short state = GetKeyState (VK_F1);
if (state < 0)
Remember that the control must have a help ID associated with it. This can be
done by taking [Properties --- General Tab --- Help ID check box]. And of course
you'll also need to write the help file for your program. Thanks.
Show MessageBox after main dialog is dismissed
Sometimes, it is required that you need to show a message box of some kind
after the main dialog in a dialog based application has been dismissed. But
you'll notice that your message box is never shown. Funnily if you put a break
point there, the program does break while debugging. The problem here is that,
in dialog based applications the
CWinThread::m_pMainWnd is the
dialog window itself and when the dialog box is dismissed the main window is
destroyed and the program exits. The solution is to comment out the line where
m_pMainWnd is set to the dialog window.
int nResponse = dlg.DoModal();
if (nResponse == IDOK)
else if (nResponse == IDCANCEL)
Of course you must not call
AfxGetMainWnd from anywhere in your
AfxGetMainWnd blindly returns the
m_pMainWnd member of your
CWinApp derived class. Otherwise
what you can do is to save your
CDialog* into some other member
m_pMainWnd2 and then write a function
which simply returns
m_pMainWnd2, if at all you badly want to use
Since I update this article very regularly I am not maintaining a complete
history, but I shall mention the last update's information here. The following
tip or tips were added in the last update which was on September 18th 2002.
- Full screen dialogs
- How to steal focus on 2K/XP