Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Child Modeless Dialogs Always Hide Parent Modeless Dialog

117 views
Skip to first unread message

RushManbert

unread,
Oct 16, 2006, 2:13:01 PM10/16/06
to
My app is dialog based. The main dialog is essentially a web browser. It has
menu items that open other modeless dialogs. (One shows the page source, one
shows the current search path set.) The problem that I am having is that the
child dialogs (source and paths view) always hide the parent. They do not
hide each other. (i.e. the active one always comes to the top of the display
stack)

The main dialog is run modeless (using Create), and has its parent window
pointer set to NULL.

I can activate the main dialog, but it remains hidden behind the others if
they are on the screen. What I want is to be able to activate any of the
three windows and have it displayed in front of the others.

I have tried the following:
1) Setting m_pMainWnd to NULL in the app's InitInstance method. This just
causes the app to close immediately after it starts.

2) Runing the main dialog using DoModal, rather than Create. This changed
nothing. (The modeless child dialogs were created and could be activated.
Somehow, I thought this wouldn't work if their parent was a modal dialog. It
seems to violate the "modal-ness" of the parent. That's why I made the main
dialog be modeless to begin with.)

3) Having the child dialogs pass a NULL pParent pointer to the CDialog
constructor. This changed nothing.

I have also edited the resource file using the text editor and made sure
that the dialogs are created with the same styles. This changed nothing.

How can this be done? I have considered making an invisible modeless dialog
that is the main window for the app, then running all of mine as children of
that one, but it seems like a rather roundabout approach. Is there something
simple that I have missed?

Thanks,
Rush

AliR

unread,
Oct 16, 2006, 2:32:33 PM10/16/06
to
This comes up many many times in this group. Do a search and you will find
alot of threads on this.

In order for to windows to switch ZOrder they will have to have the same
parent. Passing a NULL does not make the parent of the child modeless dialog
the same as the parent of the parent dialog.

So there are two things you can do.
1. You can make the main dialog of the application a hidden one, which will
act as the parent of both dialogs.
2. You can make the parent of the second dialog the desktop (only do this
for modeless dialog) GetDeskTopWindow();

AliR.


"RushManbert" <RushM...@discussions.microsoft.com> wrote in message
news:BAF13B5B-1255-494C...@microsoft.com...

RushManbert

unread,
Oct 16, 2006, 3:11:01 PM10/16/06
to

"AliR" wrote:

> This comes up many many times in this group. Do a search and you will find
> alot of threads on this.

I did do a number of Google searches, and searched here. I must be using the
wrong search terms, because I couldn't find anything useful. Sorry.

>
> In order for to windows to switch ZOrder they will have to have the same
> parent. Passing a NULL does not make the parent of the child modeless dialog
> the same as the parent of the parent dialog.
>
> So there are two things you can do.
> 1. You can make the main dialog of the application a hidden one, which will
> act as the parent of both dialogs.
> 2. You can make the parent of the second dialog the desktop (only do this
> for modeless dialog) GetDeskTopWindow();
>

Thanks for the reply. I did make a hidden top level dialog, and made my main
dialog its child. The others are still children of my main dialog, but the z
ordering now acts the way I think it should (whichever of the three is active
hides everything beneathy it on the desktop). Do I really need all three
dialogs to have the same parent? I can certainly arrange that, but it's more
complicated.

- Rush

AliR

unread,
Oct 16, 2006, 3:16:05 PM10/16/06
to
If you want all of them to be able to overlap the others then yes. That's
because a child dialog will never go behind it's parent.

AliR.

"RushManbert" <RushM...@discussions.microsoft.com> wrote in message

news:0F258022-5F3A-4485...@microsoft.com...

0 new messages