Modeless dialog on top of Modal dialog
| Author |
Message |
|
Erik Haverkam
#1 / 12
|
 Modeless dialog on top of Modal dialog Hi, I have a modeless dialog(B) that is a child of a Modal Dialog(A). (A =
dialog based application)
I start this dialog by the following code:
// get a new CBDlg instance
m_pBDlg = new CBDlg(this);
// create it as a child of the main dialog
m_pBDlg->Create(IDD_B, this);
If I move the modeless dialog(B) over dialog A and I click on dialog A, it
stays hidden behind B. Is it possible to change this behaviour? I would
really like to have the dialog A come on top of the Modeless dialog, if I
give it the focus.
Any ideas??
Thanks,
Erik
|
| Sun, 30 May 2004 20:57:48 GMT |
|
 |
|
mao
#2 / 12
|
Modeless dialog on top of Modal dialog I wonder if m_pBDlg->Create(IDD_B,NULL) will work?
Quote: > Hi, > I have a modeless dialog(B) that is a child of a Modal Dialog(A). (A =
> dialog based application)
> I start this dialog by the following code:
> // get a new CBDlg instance
> m_pBDlg = new CBDlg(this);
> // create it as a child of the main dialog
> m_pBDlg->Create(IDD_B, this);
> If I move the modeless dialog(B) over dialog A and I click on dialog A, it
> stays hidden behind B. Is it possible to change this behaviour? I would
> really like to have the dialog A come on top of the Modeless dialog, if I
> give it the focus.
> Any ideas??
> Thanks,
> Erik
|
| Sun, 30 May 2004 21:23:30 GMT |
|
|
|
Erik Haverkam
#3 / 12
|
Modeless dialog on top of Modal dialog Hi, No I tried that as well, but no succes.....I really wonder if it is
possible.
Greetings,
Erik
Quote:
>I wonder if m_pBDlg->Create(IDD_B,NULL) will work?
|
| Sun, 30 May 2004 21:49:51 GMT |
|
|
|
Carsten Schille
#4 / 12
|
Modeless dialog on top of Modal dialog Hi! I manage to get this behaviour by choosing the desktop as parent.
m_pBDlg->Create(IDD_B, GetDesktopWindow());
By the way I would be very interested in other solutions because this
creates a new icon in the task bar, which sometimes is not desired.
Cheerio,
Carsten
Quote: > I have a modeless dialog(B) that is a child of a Modal Dialog(A). (A = > dialog based application) > I start this dialog by the following code:
> // get a new CBDlg instance
> m_pBDlg = new CBDlg(this);
> // create it as a child of the main dialog
> m_pBDlg->Create(IDD_B, this);
> If I move the modeless dialog(B) over dialog A and I click on dialog A, it
> stays hidden behind B. Is it possible to change this behaviour? I would
> really like to have the dialog A come on top of the Modeless dialog, if I
> give it the focus.
> Any ideas??
> Thanks,
> Erik
|
| Sun, 30 May 2004 22:05:21 GMT |
|
|
|
Erik Haverkam
#5 / 12
|
Modeless dialog on top of Modal dialog Carsten thanks a lot, also in name of a collegue of mine!!!!!
Quote: >Hi! >I manage to get this behaviour by choosing the desktop as parent.
>m_pBDlg->Create(IDD_B, GetDesktopWindow());
>By the way I would be very interested in other solutions because this
>creates a new icon in the task bar, which sometimes is not desired.
>Cheerio,
>Carsten
|
| Sun, 30 May 2004 23:03:32 GMT |
|
|
|
Carsten Schille
#6 / 12
|
Modeless dialog on top of Modal dialog No matter, but for my feeling this is more like a workaround and for the task bar icons... Anyone? Maybe Joe... Quote: > Carsten thanks a lot, also in name of a collegue of mine!!!!! > >I manage to get this behaviour by choosing the desktop as parent.
> >m_pBDlg->Create(IDD_B, GetDesktopWindow());
> >By the way I would be very interested in other solutions because this
> >creates a new icon in the task bar, which sometimes is not desired.
|
| Sun, 30 May 2004 23:44:07 GMT |
|
|
|
Joseph M. Newcome
#7 / 12
|
Modeless dialog on top of Modal dialog The problem here is that the modeless dialog can now be covered by anything else at all. There are several alternatives; for example, using GetParent() as the parent, meaning the child modeless dialog will be coverable by the modal dialog, but not by any other app unless it is the active app. Otherwise, if you have the modeless dialog up, it can be covered by any other app, *including the app that spawned it* It will not be brought to the front when the app itself comes back to the foreground (I once used a product that did this, and we would find dozens of error dialogs behind the main app. We scrapped using that product, CodeBase) joe Quote:
>Hi! >I manage to get this behaviour by choosing the desktop as parent.
>m_pBDlg->Create(IDD_B, GetDesktopWindow());
>By the way I would be very interested in other solutions because this
>creates a new icon in the task bar, which sometimes is not desired.
>Cheerio,
>Carsten
>> I have a modeless dialog(B) that is a child of a Modal Dialog(A). (A =
>> dialog based application)
>> I start this dialog by the following code:
>> // get a new CBDlg instance
>> m_pBDlg = new CBDlg(this);
>> // create it as a child of the main dialog
>> m_pBDlg->Create(IDD_B, this);
>> If I move the modeless dialog(B) over dialog A and I click on dialog A, it
>> stays hidden behind B. Is it possible to change this behaviour? I would
>> really like to have the dialog A come on top of the Modeless dialog, if I
>> give it the focus.
>> Any ideas??
>> Thanks,
>> Erik
Joseph M. Newcomer [MVP]
Web: http://www3.pgh.net/~newcomer MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm
|
| Tue, 01 Jun 2004 01:05:44 GMT |
|
|
|
Carsten Schille
#8 / 12
|
Modeless dialog on top of Modal dialog That's exectly what I would like to avoid, but I must be missing something substantially because setting the parent dialog as parent doesn't take profit in the behaviour I would expect for me. The modeless child dialog allways stays in front of the parent modal dialog in that case, activated or not. Maybe this is standard behaviour as I can't come up with examples of standard software acting different (excepting Mac). While writing this I got a modeless dialog from outlook whose parent seems to be the desktop btw.
Quote: > The problem here is that the modeless dialog can now be covered by
anything else at all. Quote: > There are several alternatives; for example, using GetParent() as the parent, meaning the > child modeless dialog will be coverable by the modal dialog, but not by any other app > unless it is the active app. Otherwise, if you have the modeless dialog up, it can be > covered by any other app, *including the app that spawned it* It will not be brought to > the front when the app itself comes back to the foreground (I once used a product that did > this, and we would find dozens of error dialogs behind the main app. We scrapped using > that product, CodeBase) > >I manage to get this behaviour by choosing the desktop as parent.
> >m_pBDlg->Create(IDD_B, GetDesktopWindow());
> >By the way I would be very interested in other solutions because this
> >creates a new icon in the task bar, which sometimes is not desired.
|
| Tue, 01 Jun 2004 17:41:49 GMT |
|
|
|
Joseph M. Newcome
#9 / 12
|
Modeless dialog on top of Modal dialog Yes, but the behavior you describe, of a dialog staying in front of its parent, is EXACTLY what it is supposed to do! How did you determine the dialog in outlook has a parent which is the desktop? Using
Spy++? (That is the only reliable way I know to determine this).
joe
Quote:
>That's exectly what I would like to avoid, but I must be missing something >substantially because setting the parent dialog as parent doesn't take >profit in the behaviour I would expect for me. The modeless child dialog >allways stays in front of the parent modal dialog in that case, activated or >not. Maybe this is standard behaviour as I can't come up with examples of >standard software acting different (excepting Mac). While writing this I got >a modeless dialog from outlook whose parent seems to be the desktop btw.
>> The problem here is that the modeless dialog can now be covered by
>anything else at all.
>> There are several alternatives; for example, using GetParent() as the
>parent, meaning the
>> child modeless dialog will be coverable by the modal dialog, but not by
>any other app
>> unless it is the active app. Otherwise, if you have the modeless dialog
>up, it can be
>> covered by any other app, *including the app that spawned it* It will not
>be brought to
>> the front when the app itself comes back to the foreground (I once used a
>product that did
>> this, and we would find dozens of error dialogs behind the main app. We
>scrapped using
>> that product, CodeBase)
>> >I manage to get this behaviour by choosing the desktop as parent.
>> >m_pBDlg->Create(IDD_B, GetDesktopWindow());
>> >By the way I would be very interested in other solutions because this
>> >creates a new icon in the task bar, which sometimes is not desired.
Joseph M. Newcomer [MVP]
Web: http://www3.pgh.net/~newcomer MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm
|
| Thu, 03 Jun 2004 13:11:21 GMT |
|
|
|
Carsten Schille
#10 / 12
|
Modeless dialog on top of Modal dialog
Quote: > Yes, but the behavior you describe, of a dialog staying in front of its parent, is EXACTLY > what it is supposed to do! > How did you determine the dialog in outlook has a parent which is the
desktop? Using
> Spy++? (That is the only reliable way I know to determine this).
> joe
Sorry, but this was actually rather than a question *if* it is supposed to do that. I think this can cause some confusion sometimes if you would like to have a non-modal dialog to monitor data from the modal parent, but stay in the background (behind the parent)until activated (and vice-versa). This is like outlook behaves if you choose to write a new mail but it creates a new task bar icon, too (comparable to making the desktop as parent, showing parent window=none in spy++). Sorry for causing confusion again, Carsten Quote: > On Fri, 14 Dec 2001 10:41:49 +0100, "Carsten Schiller"
> >That's exectly what I would like to avoid, but I must be missing
something
> >substantially because setting the parent dialog as parent doesn't take
> >profit in the behaviour I would expect for me. The modeless child dialog
> >allways stays in front of the parent modal dialog in that case, activated
or
> >not. Maybe this is standard behaviour as I can't come up with examples of
> >standard software acting different (excepting Mac). While writing this I
got
> >a modeless dialog from outlook whose parent seems to be the desktop btw.
> >> The problem here is that the modeless dialog can now be covered by
> >anything else at all.
> >> There are several alternatives; for example, using GetParent() as the
> >parent, meaning the
> >> child modeless dialog will be coverable by the modal dialog, but not by
> >any other app
> >> unless it is the active app. Otherwise, if you have the modeless dialog
> >up, it can be
> >> covered by any other app, *including the app that spawned it* It will
not
> >be brought to
> >> the front when the app itself comes back to the foreground (I once used
a
> >product that did
> >> this, and we would find dozens of error dialogs behind the main app. We
> >scrapped using
> >> that product, CodeBase)
> >> >I manage to get this behaviour by choosing the desktop as parent.
> >> >m_pBDlg->Create(IDD_B, GetDesktopWindow());
> >> >By the way I would be very interested in other solutions because this
> >> >creates a new icon in the task bar, which sometimes is not desired.
> Joseph M. Newcomer [MVP]
> Web: http://www3.pgh.net/~newcomer
> MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm
|
| Fri, 04 Jun 2004 17:33:21 GMT |
|
|
|
Joseph M. Newcome
#11 / 12
|
Modeless dialog on top of Modal dialog Actually, I don't think it creates a modeless dialog. What it creates is probably the same kind of window Outlook Express creates, which Spy++ tells me has styles WS_OVERLAPPED and WS_OVERLAPPEDWINDOW, that is, it is not a modeless dialog at all, but an owned top-level window. Don't confuse the behaviors of the two, and if you want to find out what a Window is, Spy++ is a very handly tool. So the *real* answer is to use an owned top-level window. I'd probably experiment with using a CFormView in some way, as a start. joe Quote:
>> Yes, but the behavior you describe, of a dialog staying in front of its
>parent, is EXACTLY
>> what it is supposed to do!
>> How did you determine the dialog in outlook has a parent which is the
>desktop? Using
>> Spy++? (That is the only reliable way I know to determine this).
>> joe
>Sorry, but this was actually rather than a question *if* it is supposed to
>do that. I think this can cause some confusion sometimes if you would like
>to have a non-modal dialog to monitor data from the modal parent, but stay
>in the background (behind the parent)until activated (and vice-versa). This
>is like outlook behaves if you choose to write a new mail but it creates a
>new task bar icon, too (comparable to making the desktop as parent, showing
>parent window=none in spy++).
>Sorry for causing confusion again,
>Carsten
>> On Fri, 14 Dec 2001 10:41:49 +0100, "Carsten Schiller"
>> >That's exectly what I would like to avoid, but I must be missing
>something
>> >substantially because setting the parent dialog as parent doesn't take
>> >profit in the behaviour I would expect for me. The modeless child dialog
>> >allways stays in front of the parent modal dialog in that case, activated
>or
>> >not. Maybe this is standard behaviour as I can't come up with examples of
>> >standard software acting different (excepting Mac). While writing this I
>got
>> >a modeless dialog from outlook whose parent seems to be the desktop btw.
>> >> The problem here is that the modeless dialog can now be covered by
>> >anything else at all.
>> >> There are several alternatives; for example, using GetParent() as the
>> >parent, meaning the
>> >> child modeless dialog will be coverable by the modal dialog, but not by
>> >any other app
>> >> unless it is the active app. Otherwise, if you have the modeless dialog
>> >up, it can be
>> >> covered by any other app, *including the app that spawned it* It will
>not
>> >be brought to
>> >> the front when the app itself comes back to the foreground (I once used
>a
>> >product that did
>> >> this, and we would find dozens of error dialogs behind the main app. We
>> >scrapped using
>> >> that product, CodeBase)
>> >> >I manage to get this behaviour by choosing the desktop as parent.
>> >> >m_pBDlg->Create(IDD_B, GetDesktopWindow());
>> >> >By the way I would be very interested in other solutions because this
>> >> >creates a new icon in the task bar, which sometimes is not desired.
>> Joseph M. Newcomer [MVP]
>> Web: http://www3.pgh.net/~newcomer
>> MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm
Joseph M. Newcomer [MVP]
Web: http://www3.pgh.net/~newcomer MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm
|
| Sat, 05 Jun 2004 00:22:42 GMT |
|
|
|
Carsten Schille
#12 / 12
|
Modeless dialog on top of Modal dialog Thanks a lot for your reply, I really appreciate your work and (of course) your webpage. What I wanted to do is to get a modeless dialog which is *not* allways in front of its modal parent and which (particularly in combination) doesn't get a task bar icon of its own. This is not a real problem for me, because that "outlook like" style is ok, I'm just curious. Carsten
Quote: > Actually, I don't think it creates a modeless dialog. What it creates is probably the same > kind of window Outlook Express creates, which Spy++ tells me has styles WS_OVERLAPPED and > WS_OVERLAPPEDWINDOW, that is, it is not a modeless dialog at all, but an owned top-level > window. Don't confuse the behaviors of the two, and if you want to find out what a Window > is, Spy++ is a very handly tool. So the *real* answer is to use an owned top-level window. > I'd probably experiment with using a CFormView in some way, as a start. > joe > On Mon, 17 Dec 2001 10:33:21 +0100, "Carsten Schiller"
> >> Yes, but the behavior you describe, of a dialog staying in front of its
> >parent, is EXACTLY
> >> what it is supposed to do!
> >> How did you determine the dialog in outlook has a parent which is the
> >desktop? Using
> >> Spy++? (That is the only reliable way I know to determine this).
> >> joe
> >Sorry, but this was actually rather than a question *if* it is supposed
to
> >do that. I think this can cause some confusion sometimes if you would
like
> >to have a non-modal dialog to monitor data from the modal parent, but
stay
> >in the background (behind the parent)until activated (and vice-versa).
This
> >is like outlook behaves if you choose to write a new mail but it creates
a
> >new task bar icon, too (comparable to making the desktop as parent,
showing
> >parent window=none in spy++).
> >Sorry for causing confusion again,
> >Carsten
|
| Sat, 05 Jun 2004 17:12:06 GMT |
|
| |
|
