CreateDialog and sending a WM_NOTIFY from it

[R.Wieser]

Hello all,

Maybe a bit of an esoteric problem, but one I would want to have solved
nonetheless:

I've got a program which puts up a settings dialog (using CreateDialog).
From this settings dialog I would like to send notifications (WM_NOTIFY) to
its parent.

The problem is, the NMHDR structure expects the "idFrom" field (the control
ID) to be filled in, and I can't find it (IDD_SETTINGS, as provided to the
CreateDialog call) stored anywhere. :-|

Question:

Is it stored anywhere in the dialog, and if so, where ?

Secondary question:

Will using SetWindowLong with the GWL_ID argument on a Dialog window create
any problems (does anything else use that field) ?

Regards,
Rudy Wieser

[JJ]

Post by R.Wieser
Hello all,
Maybe a bit of an esoteric problem, but one I would want to have solved
I've got a program which puts up a settings dialog (using CreateDialog).
From this settings dialog I would like to send notifications (WM_NOTIFY) to
its parent.
The problem is, the NMHDR structure expects the "idFrom" field (the control
ID) to be filled in, and I can't find it (IDD_SETTINGS, as provided to the
CreateDialog call) stored anywhere. :-|
Is it stored anywhere in the dialog, and if so, where ?

It's stored within each window itself. Window ID is not a dialog-specific
property. It's a property which exist in all windows. But window ID is
mainly used for controls. It's rarely used for non-parented windows.

Post by R.Wieser
Will using SetWindowLong with the GWL_ID argument on a Dialog window create
any problems (does anything else use that field) ?
Regards,
Rudy Wieser

Dialogs use a set of predefined window IDs; at least for OK and Cancel
buttons. Common dialogs use more of them, including controls which are not
buttons. So it's best to avoid using their IDs to avoid disrupting or
unexpectedly triggering the dialog's default behaviour.

[R.Wieser]

JJ,

Post by JJ
It's stored within each window itself. Window ID is not a
dialog-specific property. It's a property which exist in all
windows.

I was writing a reply, when something tickled my brain.

I already tried reading the dialogs GWL_ID value, and got the value zero
back. Checking the result of the "GetLastError" call also showed a zero.
I take that as meaning a success.

... but than (now) I checked the result of a *Set*WindowLong with the GWL_ID
argument (which I should have thought of earlier).

It, and a subsequent "GetLastError", returned the value 1401, which seems to
mean "Invalid menu handle".

IOW, a (my) dialog window *doesn't* seem to have a "window ID" that can be
set. :-(

Alas.

Regards,
Rudy Wieser

[Udo Steinbach]

dialog window *doesn't* seem to have a "window ID" that can be set.

GWL_ID Sets a new identifier of the child window. The window cannot be a
top-level window.
The words are clear. If I would inform the parent or owner of a dialog, I
would call a function of the object bound to its window handle, or send or
post an own message, a registered one, or call a given call-back-function.

[R.Wieser]

Udo,

Post by Udo Steinbach

dialog window *doesn't* seem to have a "window ID" that can be set.

GWL_ID Sets a new identifier of the child window. The window cannot be
a top-level window.
The words are clear.

Yep. I assumed that as I could read from it I could write it too and didn't
read the docs for "Set" . I was wrong. :-|

Though with that question I was thinking of "will changing it possibly
disrupt the functioning of that (sub-)dialog".

Post by Udo Steinbach
If I would inform the parent or owner of a dialog, I would call a function
of
the object bound to its window handle,

You mean "objects" as one with methods, getters and setters ? I'm not
sure what that "bound to" would look like. But no, my main dialog is of
the common garden variety.

Post by Udo Steinbach
or send or post an own message, a registered one,

I have thought about the latter, but considered it to be more cumbersome
than that it would be helpfull. Both the sub-dialog and its parent
program/dialog its created by would need to do that* - and tear down
ofcourse, as its global (and I, only need it local).

*pointing to the very same string! :-)

I also considered the first one, to pick a few "random" messageID values,
and hope they do not overlap an already existing one.

Thats why I thought of using a notification message and the resource-ID I
hoped my dialog would have stored somewhere.

Post by Udo Steinbach
or call a given call-back-function.

Possible too. But than I have to make sure that that async call-back
doesn't clash with the rest of the program (having the message-loop
sequentialize all actions makes ones live easier)...

And I have to ask : is there a technical reason why I shouldn't use the
NM_NOTIFY message this way ?

Regards,
Rudy Wieser

[Woodrow Reece]

Post by R.Wieser
Hello all,
Maybe a bit of an esoteric problem, but one I would want to have solved
I've got a program which puts up a settings dialog (using CreateDialog).
From this settings dialog I would like to send notifications (WM_NOTIFY) to
its parent.
The problem is, the NMHDR structure expects the "idFrom" field (the control
ID) to be filled in, and I can't find it (IDD_SETTINGS, as provided to the
CreateDialog call) stored anywhere. :-|
Is it stored anywhere in the dialog, and if so, where ?
Will using SetWindowLong with the GWL_ID argument on a Dialog window create
any problems (does anything else use that field) ?

The WM_NOTIFY message is for a control on a dialog to send to the
dialog. Not for a dialog to send to its parent.

If your settings dialog is a control on another dialog, it must have the
styles WS_CHILD and DS_CONTROL. Only then can it have a control ID.

If your settings dialog is not a control on another dialog, you are
misusing the WM_NOTIFY message. You will be on your own.

[R.Wieser]

Woodrow,

The WM_NOTIFY message is for a control on a dialog to send to the dialog.
Not for a dialog to send to its parent.

Do you have some (preferrably MS origionated) documentation to support that
?

The dialog in question is, for all intents and purposes, a child of the
dialog that created it (they share the same message-loop).

If your settings dialog is a control on another dialog, it must have
the styles WS_CHILD and DS_CONTROL. Only then can it have a control ID.

Thank you. But no, its not.

I remember having read something about a "control parent" in relation to a
tab control. Never used it that way though.

If your settings dialog is not a control on another dialog, you are
misusing the WM_NOTIFY message. You will be on your own.

You see a problem. I don't. If you could explain that problem I would be
much obliged (it would give me a chance not to stumble into it).

Maybe you're thinking of sending such messages (containing pointers to data)
to another process ?

Regards,
Rudy Wieser.

[Newyana2]

Post by R.Wieser

The WM_NOTIFY message is for a control on a dialog to send to the dialog.
Not for a dialog to send to its parent.

Do you have some (preferrably MS origionated) documentation to support that
?

You seem to be right: "Sent by a common control to its parent
window when an event has occurred in the control or the control
requires some kind of information." (MSDN)

I'm not sure I've ever used that message. The only code I
can think of where it appears is with a RichEdit. I have to
watch for WM_NOTIFY in the subclass of the parent window
in order to get the EN_SELCHANGE RichEdit event, to know
when the selection has changed. The RichEdit sends the
WM_NOTIFY to the parent window, as MS says.

Since you haven't explained exactly what you're trying
to accomplish, this is all academic. Without context and
details it sounds like you're trying to send messages within
your own program, like a son writing a letter to his mother
and sending it through the mail, when you could use something
like an event or function, since you're writing both the parent
window and the child window.

[R.Wieser]

Newyana2,

Post by Newyana2
You seem to be right: "Sent by a common control to its parent
window when an event has occurred in the control or the control
requires some kind of information." (MSDN)

I would say I was right, I just didn't fare blindly on anyones word.
Especially not when I have not seen any info either way.

But do notice that the phrasing of the above is a bit vague: the "send ...
to its parent window" can mean what I'm doing (from one top-level dialog to
another), but as easily just that the control is talking to the window it is
placed on.

Post by Newyana2
I'm not sure I've ever used that message. The only code I
can think of where it appears is with a RichEdit.

Most, if not all of the controls that are in the ComCtl32.DLL use
notification messages. List- and treeview, list- and combobox, you name
it. Heck, I could even say that a simple button sends a notification (in
the form of a WM_COMMAND) to its parent.

Post by Newyana2
The RichEdit sends the WM_NOTIFY to the parent window, as MS says.

The difference is that I'm sending messages from one top-level dialog to
another. Yes, the first is owned by the other, but its still quite a
difference.

Post by Newyana2
Since you haven't explained exactly what you're trying to accomplish, this
is all academic.

I Think I explained it in full in my first post: I want/need to get the
"window ID" of a(n owned) dialog (the IDD_SETTINGS one that was used as an
argument to CreateDialog). Thats all. No more, no less.

So no, there is nothing academic about it ... unless you are trying to "meta
problem" the whole thing - which is not something I'm willing to participate
in.

Any talk about *the example* of what I currently wanted to use it for is, to
me, wasted time. You see, that notification already works (before I posted
my question here), even thoughI had to hard-code the "window ID".

Regards,
Rudy Wieser

p.s.
Adding the WS_CHILD attribute (with or without the DS_CONTROL attribute) to
the owned dialog doesn't make it return a "window ID" (GWL_ID), but does
allow me to set one - on the cost of the dialog becoming a control onto of
the parent - which is not at all what I need the owned dialog for. :-\

[R.Wieser]

Post by R.Wieser
I would say I was right,

I *wouldn't* say I was right,

[Newyana2]

Post by R.Wieser
I Think I explained it in full in my first post: I want/need to get the
"window ID" of a(n owned) dialog (the IDD_SETTINGS one that was used as an
argument to CreateDialog). Thats all. No more, no less.
So no, there is nothing academic about it ... unless you are trying to "meta
problem" the whole thing - which is not something I'm willing to participate
in.
Any talk about *the example* of what I currently wanted to use it for is, to
me, wasted time. You see, that notification already works (before I posted
my question here), even thoughI had to hard-code the "window ID".

And also everyone else's wasted time. The standard way to discuss
these things is to explain what you're trying to do and post your code.
With you it's always a confusing riddle. "I want to figure out the best
way to mount this plaque with bull horns on the wall." But you neglect
to mention that you haven't caught the bull yet and the mounting is set
to be 15 feet high on concrete. Meanwhile, people have been led to believe
that you're asking about picture hanging hardware.

Then someone generously offers what they know about picture
hanging hardware and you criticize them. "You fool! Did I say I want
picture hanging hardware? Show me where I said that. Show me
where I even so much as said 'hook'. Ah, why do I have to suffer fools?!"

[Woodrow Reece]

Post by R.Wieser
Woodrow,

The WM_NOTIFY message is for a control on a dialog to send to the dialog.
Not for a dialog to send to its parent.

Do you have some (preferrably MS origionated) documentation to support that
?

Yes. Quoted further down, with URL.

Post by R.Wieser
The dialog in question is, for all intents and purposes, a child of the
dialog that created it (they share the same message-loop).

In Microsoft's documentation, that is not what what a child window is.

<https://learn.microsoft.com/en-us/windows/win32/winmsg/window-features#child-windows>

Child Windows

A child window has the WS_CHILD style and is confined to the
client area of its parent window. An application typically
uses child windows to divide the client area of a parent window
into functional areas. You create a child window by specifying
the WS_CHILD style in the CreateWindowEx function.


Microsoft's documentation for WM_NOTIFY

<https://learn.microsoft.com/en-us/windows/win32/controls/wm-notify>

Sent by a common control to its parent window when an event
has occurred or the control requires some information.

[R.Wieser]

Woodrow,

Post by Woodrow Reece

Post by R.Wieser
The dialog in question is, for all intents and purposes, a child of the
dialog that created it

...

Post by Woodrow Reece
In Microsoft's documentation, that is not what what a child window is.

I know. Why do you think I said "for all intents and purposes" ?

Post by Woodrow Reece
Microsoft's documentation for WM_NOTIFY

...

Post by Woodrow Reece
Sent by a common control to its parent window when an event has occurred
or the control requires some information.

Absolutily true.

The problem is that you read that as an exclusion of everything else. I
don't.

I have a counter example :

https://learn.microsoft.com/en-us/windows/win32/dlgbox/customizing-common-dialog-boxes

[quote]
Common dialog boxes use messages to notify your window procedure or hook
procedure when certain events occur.
[/quote]

By the way: I really hate it that MS talks about "windows" regardless of if
they are used as controls or ... whats the name for a window thats used to
place controls on ? You know, the equivalent of a Dialog. The ambiguity of
that word makes it quite hard to be certain what their own documentation is
actually talking about. :-(

Regards,
Rudy Wieser

[Woodrow Reece]

Post by R.Wieser
Woodrow,

Post by Woodrow Reece

Post by R.Wieser
The dialog in question is, for all intents and purposes, a child of the
dialog that created it

...

Post by Woodrow Reece
In Microsoft's documentation, that is not what what a child window is.

I know. Why do you think I said "for all intents and purposes" ?

You gave us intents and purposes for which it is not a child window. You
failed to get a control ID from your dialog. You then failed to set a
control ID on the dialog itself.

Post by R.Wieser

Post by Woodrow Reece
Microsoft's documentation for WM_NOTIFY

...

Post by Woodrow Reece
Sent by a common control to its parent window when an event has occurred
or the control requires some information.

Absolutily true.
The problem is that you read that as an exclusion of everything else. I
don't.

You asked me for MS originated documentation. That is what I gave you.

Now you are putting words in my mouth. I am not responsible for your
failures to get or set the control ID which you wanted.

[R.Wieser]

Woodrow,

Post by Woodrow Reece

Post by R.Wieser

Post by Woodrow Reece

Post by R.Wieser
The dialog in question is, for all intents and purposes, a child of
the dialog that created it

...

Post by Woodrow Reece
In Microsoft's documentation, that is not what what a child window is.

I know. Why do you think I said "for all intents and purposes" ?

You gave us intents and purposes for which it is not a child window.
You failed to get a control ID from your dialog. You then failed to
set a control ID on the dialog itself.

Nope, nope and nope.

Nope #1: You can say that, but as you have not tried to explain, let alone
support it its meaningless.

As long as you do not explain, let alone suport that stance of yours tits
meaningless.

Nope #2: You're mistaken. I did get a control ID form my dialog (as you
/could/ have read in a previous message), it just always is Zero.

Nope #3: You lack imagination and/or knowledge. GWL_ID is not the only
index there you know. And than you have the possibility of super- or
subclassing ofcourse.

So, do you want to try again ?

Post by Woodrow Reece
You asked me for MS originated documentation. That is what I gave you.

No, I didn't and no, you didn't.

I asked you for documenation *that would support* your POV, /preferrably/
from MS. You than came up with something you had to interpret to make it
sound as if it did.

I countered that. But instead of explaining/supporting your interpretation
and/or pointing out the flaw in mine you just repeated it. I'm sorry, but
that doesn't work for me.

Also, I gave you a counter example, one you have not even tried to address,
let alone counter. That also doesn't work for me.

Post by Woodrow Reece
Now you are putting words in my mouth.

As that document doesn't explicitily support your POV and you didn't try to
explain how it does, what did you think would happen ?

Also, you could have addressed it and set the record straight. Why didn't
you ?

Post by Woodrow Reece
I am not responsible for your failures to get or set the control ID which
you wanted.

You're quite a piece of work. :-) We where talking about the NM_NOTIFY
message in relation to Dialogs, and suddenly I'm holding you responsible for
what I can('t) to with the contol ID ? How did you figure that ?

... or is this just you putting words into my mouth ? <whistle>

Regards,
Rudy Wieser

[Charlie Gibbs]

Post by R.Wieser
By the way: I really hate it that MS talks about "windows" regardless of if
they are used as controls or ... whats the name for a window thats used to
place controls on ? You know, the equivalent of a Dialog. The ambiguity of
that word makes it quite hard to be certain what their own documentation is
actually talking about. :-(

[shrug]
In Unix, everything is a file.
In Windows, everything is a window.