f



EndDialog -- Where is the flag stored ?

Hello All,

The 'EndDialog' function sets a flag to indicate that the dialogs
messageloop should terminate (and than posts a WM_NULL to make the loop
check the flag).

Does anyone have an idea where that flag is stored / how to check that flag
?

Reason: I need to add a MsgWaitForMultipleObjects to a dialog, and thus need
to write my own message loop.  My intention is to mimic the origional
dialogs message-loop as closely as I can, so that *no other changes* are
needed.

Regards,
Rudy Wieser



0
R
12/12/2016 1:01:01 AM
comp.os.programmer.win32 14523 articles. 0 followers. Post Follow

19 Replies
315 Views

Similar Articles

[PageSpeed] 46

David,

From that link you posted:

[quote]
ESC Sends a WM_COMMAND message to the dialog box procedure. The wParam
parameter is set to IDCANCEL.
[/quote]

Alas, that *doesn't* seem to happen when you have a *multiline* textbox.
Believe me, if it would I would have noticed it by now.   I suggest you try
for yourself.

Furthermore, from the first result page when I googeled for "win32 editbox
multiline ESC":

http://stackoverflow.com/questions/21358802/win32-api-how-to-catch-escape-ke
y-in-edit-control

http://www.williamwilling.com/blog/?p=28

http://forums.codeguru.com/printthread.php?t=346327&pp=15

It looks like I'm not the only one who noticed this behaviour. :-)



But, all of this side-tracks the origional issue:

> It sounds like you might be trying to fix the wrong problem.

If you have any idea what the right problem is and how to fix it than I
would be obliged.

Regards,
Rudy Wieser


-- Origional message"
David Lowndes <DavidL@example.invalid> schreef in berichtnieuws
ufut4ctfp3vro3jatu3q77ecmt49ajp54m@4ax.com...
> >> ... and the dialog manager that interprets ESC to be cancel
> >
> >Ehrmmm ...   Unless you mean something completely different with "dialog
> >manager" than the callback function you provide to, for example, a
> >'DialogBox' call I don't think so.
>
> See here:
>
>
https://msdn.microsoft.com/en-us/library/windows/desktop/ms644995(v=vs.85).a
spx#keyboard_iface
>
> Dave


0
R
12/12/2016 1:01:01 AM
JJ,

> Also keep in mind that it's a ReactOS source code, not Microsoft Windows.

:-) I was aware of/wondered about that, but currently I've got nothing and
are pretty-much accepting *anything* that looks promising..

> PS) You're trying to hack - in case you don't realize yet. ;)

:-p Thats also something I was wondering about, but first wanted to have a
complete picture to be able to see of what level it would be.   And maybe
with some info I can actually find some actual MS documentation about it
(hey, I can always hope, can't I ? :-) )

And I do not know how you think about it, but I find it rather odd that some
pivotical element of a dialogs message loop is not available to the
programmer, meaning that the only way to get an MsgWaitForMultipleObjects to
function in a dialog is to break some of its functionality (in case you're
wondering what I'm talking about: a multiline textbox will terminate a
dialog whe ESC is pressed, but won't do the same with a normal window - due
to the textbox invoking EndDialog).

Regards,
Rudy Wieser


-- Origional message:
JJ <jj4public@vfemail.net> schreef in berichtnieuws
1jvqcxuj9b2mx$.1vau3dv5guq3b.dlg@40tude.net...
> On Mon, 12 Dec 2016 13:06:30 +0100, R.Wieser wrote:
> > Christian,
> >
> >> It is stored in the Dialog Box internal structure, so not easy to get
> >
> > Thanks!   I've been looking for that for quite some time.
> >
> > One question though: how do I retrieve the address of the _DLG structure
?
> > I take it its not the result of a DialogBoxParam function.
> >
> > (the Wiki does not show any way to navigate to relevant related info,
> > otherwise I've would have done so ...)
>
> That code was 5 years old. I can't find it in current ReactOS SVN.
>
> <http://code.reactos.org/browse/reactos/trunk>
>
> Also keep in mind that it's a ReactOS source code, not Microsoft Windows.
> There's a high probability that the structure data are not identical.
> Finding the structure and field for Microsoft Window would involve
debugging
> the User library. And mind you, even if you found it, the structure can be
> different across Windows versions.
>
> PS) You're trying to hack - in case you don't realize yet. ;)


0
R
12/12/2016 1:01:01 AM
R.Wieser a �crit :
> Hello All,
>
> The 'EndDialog' function sets a flag to indicate that the dialogs
> messageloop should terminate (and than posts a WM_NULL to make the loop
> check the flag).
>
> Does anyone have an idea where that flag is stored / how to check that flag
> ?

It is stored in the Dialog Box internal structure, so not easy to get 
(fEnd):

https://reactos.org/wiki/Techwiki:Win32k/DLG

0
Christian
12/12/2016 11:43:18 AM
Christian,

> It is stored in the Dialog Box internal structure, so not easy to get

Thanks!   I've been looking for that for quite some time.

One question though: how do I retrieve the address of the _DLG structure ?
I take it its not the result of a DialogBoxParam function.

(the Wiki does not show any way to navigate to relevant related info,
otherwise I've would have done so ...)

Regards,
Rudy Wieser


-- Origional message:
Christian Astor <castorix@club-internet.fr> schreef in berichtnieuws
o2m2gm$14ug$1@gioia.aioe.org...
> R.Wieser a �crit :
> > Hello All,
> >
> > The 'EndDialog' function sets a flag to indicate that the dialogs
> > messageloop should terminate (and than posts a WM_NULL to make the loop
> > check the flag).
> >
> > Does anyone have an idea where that flag is stored / how to check that
flag
> > ?
>
> It is stored in the Dialog Box internal structure, so not easy to get
> (fEnd):
>
> https://reactos.org/wiki/Techwiki:Win32k/DLG
>


0
R
12/12/2016 12:06:30 PM
On Mon, 12 Dec 2016 13:06:30 +0100, R.Wieser wrote:
> Christian,
> 
>> It is stored in the Dialog Box internal structure, so not easy to get
> 
> Thanks!   I've been looking for that for quite some time.
> 
> One question though: how do I retrieve the address of the _DLG structure ?
> I take it its not the result of a DialogBoxParam function.
> 
> (the Wiki does not show any way to navigate to relevant related info,
> otherwise I've would have done so ...)

That code was 5 years old. I can't find it in current ReactOS SVN.

<http://code.reactos.org/browse/reactos/trunk>

Also keep in mind that it's a ReactOS source code, not Microsoft Windows.
There's a high probability that the structure data are not identical.
Finding the structure and field for Microsoft Window would involve debugging
the User library. And mind you, even if you found it, the structure can be
different across Windows versions.

PS) You're trying to hack - in case you don't realize yet. ;)
0
JJ
12/12/2016 3:55:45 PM
>...(in case you're
>wondering what I'm talking about: a multiline textbox will terminate a
>dialog whe ESC is pressed, but won't do the same with a normal window - due
>to the textbox invoking EndDialog).

It's not the text box doing that, it's the fact that the dialog
responds to IDCANCEL and the dialog manager that interprets ESC to be
cancel - which generally gives the consistent behaviour that you want
from a dialog box.

I'm not really sure what it is that you're trying to circumvent with
this endeavor. It sounds like you might be trying to fix the wrong
problem.

Dave
0
David
12/12/2016 5:26:52 PM
David,

> ... and the dialog manager that interprets ESC to be cancel

Ehrmmm ...   Unless you mean something completely different with "dialog
manager" than the callback function you provide to, for example, a
'DialogBox' call I don't think so.

You see, if that would be true I would 1) see that message come by -- which
doesn't  2) a button with an IDCANCEL control ID would give the same
effect -- which it doesn't (just checked to make absolutily sure).

> It sounds like you might be trying to fix the wrong problem.

Hey, don't stop there !   What is, according to you, the problem and its
solution - I'm all ears (won't promiss I will agree with you, but I will
definitily listen :-) )

Regards,
Rudy Wieser


-- Origional message:
David Lowndes <DavidL@example.invalid> schreef in berichtnieuws
16nt4c9aatuhfl1rahhkq025fsrtkq0348@4ax.com...
> >...(in case you're
> >wondering what I'm talking about: a multiline textbox will terminate a
> >dialog whe ESC is pressed, but won't do the same with a normal window -
due
> >to the textbox invoking EndDialog).
>
> It's not the text box doing that, it's the fact that the dialog
> responds to IDCANCEL and the dialog manager that interprets ESC to be
> cancel - which generally gives the consistent behaviour that you want
> from a dialog box.
>
> I'm not really sure what it is that you're trying to circumvent with
> this endeavor. It sounds like you might be trying to fix the wrong
> problem.
>
> Dave


0
R
12/12/2016 5:48:40 PM
>> ... and the dialog manager that interprets ESC to be cancel
>
>Ehrmmm ...   Unless you mean something completely different with "dialog
>manager" than the callback function you provide to, for example, a
>'DialogBox' call I don't think so.

See here:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms644995(v=vs.85).aspx#keyboard_iface

Dave
0
David
12/12/2016 7:31:00 PM
JJ a �crit :

> That code was 5 years old. I can't find it in current ReactOS SVN.
>
> <http://code.reactos.org/browse/reactos/trunk>
>
> Also keep in mind that it's a ReactOS source code, not Microsoft Windows.
> There's a high probability that the structure data are not identical.
> Finding the structure and field for Microsoft Window would involve debugging
> the User library. And mind you, even if you found it, the structure can be
> different across Windows versions.
>
> PS) You're trying to hack - in case you don't realize yet. ;)


Those structures have not changed.
I just tested on Windows 7 SP1 32-bit : I set fEnd = 1, then I send 
WM_NULL and the Dialog box is closed.
I got the pointer by calling gSharedInfo API from USER32.DLL 
(PSHAREDINFO structure) to get the PWND handle from the handle table and 
cast (((PDIALOG)PWND)->pdlg)

But it is complicated and as David Lowndes said above, I don't think  it 
is the right way.

0
Christian
12/12/2016 8:09:12 PM
>Alas, that *doesn't* seem to happen when you have a *multiline* textbox.
>Believe me, if it would I would have noticed it by now.   I suggest you try
>for yourself.

Works for me.

Create a new Win32 project with VS. In the About dialog, add an edit
control and set it to multiline.

Build/run the project, Help About, move focus to the multiline edit
control, press Esc - the dialog closes as it should do.

I can't give you an answer to your problem, because I don't know why
you're in the situation of needing to use MsgWaitForMultipleObjects
from a dialog, and I suspect the reason may be too complicated to
convey adequately in an online support mechanism like this.

If you need to process things in your main message loop, one
possibility may be to use a modeless dialog instead of a modal one -
and if necessary disable your main frame window while the dialog is
active in order to simulate the same behaviour as a modal dialog.

Dave
0
David
12/12/2016 8:16:26 PM
On 2016-12-12, Christian Astor <castorix@club-internet.fr> wrote:
> JJ a écrit :
>
>> That code was 5 years old. I can't find it in current ReactOS SVN.
>>
>> <http://code.reactos.org/browse/reactos/trunk>
>>
>> Also keep in mind that it's a ReactOS source code, not Microsoft Windows.
>> There's a high probability that the structure data are not identical.
>> Finding the structure and field for Microsoft Window would involve debugging
>> the User library. And mind you, even if you found it, the structure can be
>> different across Windows versions.
>>
>> PS) You're trying to hack - in case you don't realize yet. ;)
>
>
> Those structures have not changed.
> I just tested on Windows 7 SP1 32-bit : I set fEnd = 1, then I send 
> WM_NULL and the Dialog box is closed.

A flag *and* a message?

I'm surprised it doesn't also monitor the audio input for the magic
words "Simon says close the fucking dialog".
0
Kaz
12/12/2016 10:17:38 PM
Christian,

> I got the pointer by calling gSharedInfo API from USER32.DLL
> (PSHAREDINFO structure) to get the PWND handle from the
> handle table and cast (((PDIALOG)PWND)->pdlg)

Thank you.  I was trying to go the IsWindow way (which, as some
disassembling showed, returns a pointer which has the _DIALOG data at offset
0x38), but both had no clue to how to get at the _DLG structures data as
well as being quite unsure if that was the right way to go.

> But it is complicated and as David Lowndes said above, I don't
> think it is the right way.

Agreed, I also do not think its the right way.  But as nothing is documented
as exposed to the programmer he does not have much choice, now does he ?

And I extend the same invitation to you as I did to David: if you know a
better way than you're very much invited to share it.

Regards,
Rudy Wieser


-- Origional message:
Christian Astor <castorix@club-internet.fr> schreef in berichtnieuws
o2n057$10ah$1@gioia.aioe.org...
> JJ a �crit :
>
> > That code was 5 years old. I can't find it in current ReactOS SVN.
> >
> > <http://code.reactos.org/browse/reactos/trunk>
> >
> > Also keep in mind that it's a ReactOS source code, not Microsoft
Windows.
> > There's a high probability that the structure data are not identical.
> > Finding the structure and field for Microsoft Window would involve
debugging
> > the User library. And mind you, even if you found it, the structure can
be
> > different across Windows versions.
> >
> > PS) You're trying to hack - in case you don't realize yet. ;)
>
>
> Those structures have not changed.
> I just tested on Windows 7 SP1 32-bit : I set fEnd = 1, then I send
> WM_NULL and the Dialog box is closed.
> I got the pointer by calling gSharedInfo API from USER32.DLL
> (PSHAREDINFO structure) to get the PWND handle from the handle table and
> cast (((PDIALOG)PWND)->pdlg)
>
> But it is complicated and as David Lowndes said above, I don't think  it
> is the right way.
>


0
R
12/13/2016 1:01:01 AM
David,

> Build/run the project, Help About, move focus to the multiline
> edit control, press Esc - the dialog closes as it should do.

True, it should (read: it has been programmed to do so).  But you're
skipping something rather important: *why* does it close.

You have not mentioned you are handling a WMCOMMAND + IDCANCEL combination,
so what is causing your dialog to close: *you* didn't instruct it to do so.

And if a WM_COMMAND + IDCANCEL should actually close a dialog, why doesn't
that happen for a single-line editbox (which fires off the same
combination -- or, as I indicated, for a button generating the same
combination) ?

> I can't give you an answer to your problem, because I don't know
> why you're in the situation of needing to use MsgWaitForMultipleObjects
> from a dialog

Wrong approach.  You're not out to solve the problem, you're out to evade
and ignore it.

And by the way: whats the most obvious reason why I would need it ?  Thats
right, I have an event I need to catch.

> and I suspect the reason may be too complicated to convey
> adequately in an online support mechanism like this.

Lol ?   I need to catch an event.   Nothing complicated about it.

If you have a solution where I can have a responsive dialog which also can
catch events (and fire-off messages into the dialog) you're welcome to share
it.

.... but I'm than quite sure you will go into the realm of multiple threads,
which has its own problems (what makes you think I did not also think of
that and tried it ? :-) ).

> If you need to process things in your main message loop, one
> possibility may be to use a modeless dialog instead of a modal
> one

You're again going off on a tangent which has got *zero* to do with the
problem as I've posted it.

That, and what makes you think I've not already done so (calling a
'CreateDialog' instead of a 'DialogBox') and the very reason why I have the
need to emulate a dialogs message loop ?

Regards,
Rudy Wieser


-- Origional message:
David Lowndes <DavidL@example.invalid> schreef in berichtnieuws
ss0u4clg5kefj8jp7jq795ovqcth11hc6s@4ax.com...
> >Alas, that *doesn't* seem to happen when you have a *multiline* textbox.
> >Believe me, if it would I would have noticed it by now.   I suggest you
try
> >for yourself.
>
> Works for me.
>
> Create a new Win32 project with VS. In the About dialog, add an edit
> control and set it to multiline.
>
> Build/run the project, Help About, move focus to the multiline edit
> control, press Esc - the dialog closes as it should do.
>
> I can't give you an answer to your problem, because I don't know why
> you're in the situation of needing to use MsgWaitForMultipleObjects
> from a dialog, and I suspect the reason may be too complicated to
> convey adequately in an online support mechanism like this.
>
> If you need to process things in your main message loop, one
> possibility may be to use a modeless dialog instead of a modal one -
> and if necessary disable your main frame window while the dialog is
> active in order to simulate the same behaviour as a modal dialog.
>
> Dave



0
R
12/13/2016 1:01:01 AM
Kaz,

> A flag *and* a message?

Yep.   The message pump is only there for *posted* messages.  If that
(WM_NULL) message would not be posted than the message pump would not loop
and the exit flag would not get checked until the dialog would generate a
posted message itself (like WM_PAINT), causing the (still active!) program
to linger in memory.


.... but it made me wonder why not simply a WM_QUIT message could be posted
(instead of the WM_NULL one).   Maybe I will stumble over that answer
somewhere sometime too ... :-)

Regards,
Rudy Wieser


-- Origional mesage:
Kaz Kylheku <221-501-9011@kylheku.com> schreef in berichtnieuws
20161212141431.159@kylheku.com...
> On 2016-12-12, Christian Astor <castorix@club-internet.fr> wrote:
> > JJ a �crit :
> >
> >> That code was 5 years old. I can't find it in current ReactOS SVN.
> >>
> >> <http://code.reactos.org/browse/reactos/trunk>
> >>
> >> Also keep in mind that it's a ReactOS source code, not Microsoft
Windows.
> >> There's a high probability that the structure data are not identical.
> >> Finding the structure and field for Microsoft Window would involve
debugging
> >> the User library. And mind you, even if you found it, the structure can
be
> >> different across Windows versions.
> >>
> >> PS) You're trying to hack - in case you don't realize yet. ;)
> >
> >
> > Those structures have not changed.
> > I just tested on Windows 7 SP1 32-bit : I set fEnd = 1, then I send
> > WM_NULL and the Dialog box is closed.
>
> A flag *and* a message?
>
> I'm surprised it doesn't also monitor the audio input for the magic
> words "Simon says close the fucking dialog".


0
R
12/13/2016 1:01:01 AM
David,

> I originally wrote:
>
> "It's not the text box doing that, it's the fact that the dialog
> responds to IDCANCEL..."

And I said that it doesn't *and* described the reasone to why I think so.
As long as you do not post anything substanciating your own stance and/or
pointing out a flaw to my reasoning I'm considering this closed.

> It does. Change the edit control in the clean test project back
> to single line and try it.

No, it doesn't.    Not without adding code to capture WM_COMMAND, checking
for IDCANCEL and than calling EndDialog to the dialogs procedure.

And yes, I did see that WM_COMMAND + IDCANCEL come by.  A few days ago, when
I tested it myself.

But you're *again* focussing on the wrong thing:  Do you see a WM_COMMAND +
IDCANCEL come by when you have a multiline textbox and press ESC ?   If not
(and you won't), why-and-how than does the dialog close ?  *THATS* the
problem.

And by the way: I get a feeling that your "clean test project" isn't as
clean as you think it is.  It might just be possible that your wizzard
auto-adds that WM_COMMAND +IDCANCEL checking to the dialogs procedure.

> I'll leave you be now.

That would be better, yes.

Regards,
Rudy Wieser


-- Origional message:
David Lowndes <DavidL@example.invalid> schreef in berichtnieuws
3bkv4c9irdu12q4ejnqdjns36s6qa2hn20@4ax.com...
> >You have not mentioned you are handling a WMCOMMAND + IDCANCEL
combination,
> >so what is causing your dialog to close: *you* didn't instruct it to do
so.
>
> I originally wrote:
>
> "It's not the text box doing that, it's the fact that the dialog
> responds to IDCANCEL..."
>
> >And if a WM_COMMAND + IDCANCEL should actually close a dialog, why
doesn't
> >that happen for a single-line editbox
>
> It does. Change the edit control in the clean test project back to
> single line and try it.
>
> I'll leave you be now.
>
> Dave



0
R
12/13/2016 1:01:01 AM
Christian,

> WM_COMMAMD + IDCANCEL is sent if the default WM_CLOSE
> is not intercepted.

I read that too, yes.   I also read that leaving WM_CLOSE out would be
unadvisable, as that makes the taskmanagers job difficult.

But that does not even matter.   What does is that the multiline textbox
control decides for itself that it will close a dialog on its own (and only
than and with that one, won't try it when its placed in a simple window or
is single line).

And the fact that that fsicking textbox will even *force* its way when you
try to stop it (by not letting the dialogs procedure handle WM_CLOSE) is
simply the pits.

What where they thinking there at MS headquarters ?  That a programmer would
not be able to write code to capture a WM_COMMAND + IDCANCEL and act
accordingly by themselves and would therefore "help" them this way (*without
offering a possibility to disable that behaviour*) ?

Bunch of morons ...

Regards,
Rudy Wieser


-- Origional message:
Christian Astor <castorix@club-internet.fr> schreef in berichtnieuws
o2p7gd$gi9$1@gioia.aioe.org...
> R.Wieser a �crit :
>
>
> > But you're *again* focussing on the wrong thing:  Do you see a
WM_COMMAND +
> > IDCANCEL come by when you have a multiline textbox and press ESC ?   If
not
> > (and you won't), why-and-how than does the dialog close ?  *THATS* the
> > problem.
>
> WM_COMMAMD + IDCANCEL is sent if the default WM_CLOSE is not intercepted.
>
> The Multiline Edit control handles VK_ESC, then posts WM_CLOSE
> The Dialog Manager handles WM_CLOSE, checks if IDCANCEL is not disabled
> and sends BN_CLICKED to IDCANCEL
>
> (at least on Windows 7 and from XP IIRC)
>



0
R
12/13/2016 1:01:01 AM
Christian, JJ, David,

Having looked at the possibilities and their portability between versions of
Windows I must conceede that its impossible to mimic a dialogs message loop
without doing "some hackish stuff"(tm) (which I'm not really a fan of).

The next-best solution looks to be to append a WM_QUIT posting
(PostQuitMessage ?) to any EndDialog calling.

Thanks for the thinking along.

Regards,
Rudy Wieser


-- Origional message:
Christian Astor <castorix@club-internet.fr> schreef in berichtnieuws
o2n057$10ah$1@gioia.aioe.org...
> JJ a �crit :
>
> > That code was 5 years old. I can't find it in current ReactOS SVN.
> >
> > <http://code.reactos.org/browse/reactos/trunk>
> >
> > Also keep in mind that it's a ReactOS source code, not Microsoft
Windows.
> > There's a high probability that the structure data are not identical.
> > Finding the structure and field for Microsoft Window would involve
debugging
> > the User library. And mind you, even if you found it, the structure can
be
> > different across Windows versions.
> >
> > PS) You're trying to hack - in case you don't realize yet. ;)
>
>
> Those structures have not changed.
> I just tested on Windows 7 SP1 32-bit : I set fEnd = 1, then I send
> WM_NULL and the Dialog box is closed.
> I got the pointer by calling gSharedInfo API from USER32.DLL
> (PSHAREDINFO structure) to get the PWND handle from the handle table and
> cast (((PDIALOG)PWND)->pdlg)
>
> But it is complicated and as David Lowndes said above, I don't think  it
> is the right way.



0
R
12/13/2016 1:01:01 AM
>You have not mentioned you are handling a WMCOMMAND + IDCANCEL combination,
>so what is causing your dialog to close: *you* didn't instruct it to do so.

I originally wrote:

"It's not the text box doing that, it's the fact that the dialog
responds to IDCANCEL..."

>And if a WM_COMMAND + IDCANCEL should actually close a dialog, why doesn't
>that happen for a single-line editbox

It does. Change the edit control in the clean test project back to
single line and try it.

I'll leave you be now.

Dave
0
David
12/13/2016 10:52:27 AM
R.Wieser a �crit :


> But you're *again* focussing on the wrong thing:  Do you see a WM_COMMAND +
> IDCANCEL come by when you have a multiline textbox and press ESC ?   If not
> (and you won't), why-and-how than does the dialog close ?  *THATS* the
> problem.

WM_COMMAMD + IDCANCEL is sent if the default WM_CLOSE is not intercepted.

The Multiline Edit control handles VK_ESC, then posts WM_CLOSE
The Dialog Manager handles WM_CLOSE, checks if IDCANCEL is not disabled 
and sends BN_CLICKED to IDCANCEL

(at least on Windows 7 and from XP IIRC)

0
Christian
12/13/2016 4:26:53 PM
Reply: