Re: modeless dialog boxes and z order

[Joseph M. Newcomer]

This is contrary to how dialogs work. Modeless dialogs are normally on top of their
parent. You can make the desktop window their parent, and this leads to other serious
consequences,

It is Windows handling the issue. SetWindowPos can adjust the relative positions of the
dialogs with respect to each other's Z-order, but they will necessarily be on top of their
parent, because that's how dialogs are implemented. By the way, did you check the result
of SetWindowPos to see if it actually worked?
joe

On Wed, 22 Aug 2007 16:58:02 -0700, CharlieB <Char...@newsgroups.nospam> wrote:

>My dialog based app creates several modeless dialogs. I want the window with
>focus to always be on top. So I want the modeless dialogs on top when
>activated. I want the main window on top when it is activated (click on it).
> I know this is contrary to standard behavior. I also know I may end up
>with hidden windows and have a plan. At this point however I cannot find a
>way for a modeless dialog to be below the window that created it.
>
>I have tried many different calls to SetWindowPos but somehow either MFC or
>Windows overrides these.
>
>Any help greatly appreciated.
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

[Joseph M. Newcomer]

By the way, the way I handled this was simply to minimize the modeless dialogs, which
works very well.

[AliR (VC++ MVP)]

I am not a big fan of making the desktop the parent of a child window, but
that is what you will have to do when you create your child dialogs.

The other solution that Joe didn't talk about is having a hidden main
window/dialog that is the parent of all the other visible window/dialogs in
your application.

AliR.

"CharlieB" <Char...@newsgroups.nospam> wrote in message
news:A01E0742-A183-4FD7...@microsoft.com...

> My dialog based app creates several modeless dialogs. I want the window
> with
> focus to always be on top. So I want the modeless dialogs on top when
> activated. I want the main window on top when it is activated (click on
> it).
> I know this is contrary to standard behavior. I also know I may end up
> with hidden windows and have a plan. At this point however I cannot find
> a
> way for a modeless dialog to be below the window that created it.
>
> I have tried many different calls to SetWindowPos but somehow either MFC
> or
> Windows overrides these.
>
> Any help greatly appreciated.

> --
> Charlie

[David Webber]

"CharlieB" <Char...@newsgroups.nospam> wrote in message
news:A01E0742-A183-4FD7...@microsoft.com...

> My dialog based app creates several modeless dialogs. I want the window
> with
> focus to always be on top. So I want the modeless dialogs on top when
> activated. I want the main window on top when it is activated (click on
> it).
> I know this is contrary to standard behavior.

So, when you are entering stuff into your main window, your modeless
dialogues are quite possibly going to be completely hidden behind it, making
it impossible to click on one to reactivate it.

Solution: a toolbar button to reactivate each modeless dialogue.

No we have go that far, why not just hide the modeless dialogue when your
main window has the focus and show it with the toolbar button you needed
anyway? Then your program can conform to the usual paradigm that dialogues
are descendants of application windows and children are always on top of
parents (or hidden).

Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mzusers/mailinglist.htm

[Tom Serface]

Hi Dave,

I also like this approach (using a toolbar or other button to re-show the
window). You don't really need to destroy the dialog, you can simply hide
it or just bring it to the top again when the button is pressed so the user
can see it.

This might be an application for a tabbed dialog or property sheet as well.
Unless there is some reason for the dialogs to float around (like the user
wants to place them on the screen) tabs make it really easy to switch
between screens. Of course, with tabs only one shows at a time, but you
don't have to wonder where the others went.

I also like the "Office" approach where they create a separate "window" for
each open document so you can just click on the task bar button (or from the
list that pops up from the grouped button) to get back to the document.

OP could also have a Wiindow menu that the user could use to pop up the
windows again. If the window is already open then just pop it to the front.
If it is not open, then open it and pop it to the front.

Tom

"David Webber" <da...@musical-dot-demon-dot-co.uk> wrote in message
news:%23LdmUOX...@TK2MSFTNGP04.phx.gbl...

[Okie]

I have written a couple of apps that use the desktop as parent for modeless
sub-dialogs so they can be moved behind the main, and have not *discovered*
any show-stoppers (yet). That's not to say there are none, but if there are
any no one's seen them after several years of regular use.

Each of the modeless child-of-the-desktop dialogs automatically has its own
icon on the taskbar. If they are completely hidden by the main (or any
other) dialog, clicking that taskbar icon brings it to the top of the pile
again. In addition, the app is written so that the same action that opens
the modeless dialog in the first place (a button on the main dialog or one of
the sub-dialogs, or a menu selection) will simply bring it to the top if it
is already open. Easy.

I am working with laptop systems where screen real estate is scarce and
valuable; being able to shuffle the main and sub dialogs as needed at any
given moment makes the user's life much easier. I realize that this is a
work-around (a.k.a. "kludge"), but it works, does what I need it to do, and,
to my knowledge, hasn't produced any undesirable side effects in years of
operation. I use them myself, and the other users have no qualms about
letting me know about deficiencies in the programs! YMMV.

[CharlieB]

Could you explain what other problem you refer to should the desktop be the
parent? I saw a similar solution on another service and the poster had asked
if this approach was ok. What bad things happen if you make the desktop the
parent?
--
Charlie

[Joseph M. Newcomer]

Mostly the problem deals with what the parent is. Dialogs that have the desktop as parent
can be hidden by ANY other app, not just yours; therefore, they can be hard to find, which
is very awkward for the end user. I have found the resulting confusion difficult for end
users to deal with, which is why I abandoned this by 1992.

Note that you can also use the concept of "multiple top-level windows" in some cases to
get this effect, although the old VB interface worked this way, and was ultimately
abandoned as a fundamentally screwed-up interface; it works well only when all the
top-level windows are essentially identical.

I found the "minimize" approach to work much better when I need modeless dialogs.
joe

On Wed, 22 Aug 2007 23:00:01 -0700, CharlieB <Char...@newsgroups.nospam> wrote:

>Could you explain what other problem you refer to should the desktop be the
>parent? I saw a similar solution on another service and the poster had asked
>if this approach was ok. What bad things happen if you make the desktop the
>parent?