XPost: alt.windows7.general, comp.os.ms-windows.programmer.win32

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.windows7.general, comp.os.ms-windows.programmer.win32

On Thu, 14 Nov 2024 08:54:14 +0100, R.Wieser wrote:

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 ?

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.

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

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.windows7.general, comp.os.ms-windows.programmer.win32

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.windows7.general, comp.os.ms-windows.programmer.win32

R.Wieser wrote:

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) ?

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.windows7.general, comp.os.ms-windows.programmer.win32

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.windows7.general, comp.os.ms-windows.programmer.win32

On 11/17/2024 2:26 AM, R.Wieser wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.windows7.general, comp.os.ms-windows.programmer.win32

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.

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.

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.

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. :-\

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.windows7.general, comp.os.ms-windows.programmer.win32

I would say I was right,

I *wouldn't* say I was right,

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.windows7.general, comp.os.ms-windows.programmer.win32

R.Wieser wrote:

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.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.windows7.general, comp.os.ms-windows.programmer.win32

On 11/17/2024 11:26 AM, R.Wieser wrote:

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?!"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.windows7.general, comp.os.ms-windows.programmer.win32

Woodrow,

The dialog in question is, for all intents and purposes, a child of the
dialog that created it

...

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" ?

Microsoft's documentation for WM_NOTIFY

...

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.windows7.general, comp.os.ms-windows.programmer.win32

R.Wieser wrote:

Woodrow,

The dialog in question is, for all intents and purposes, a child of the
dialog that created it

...

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.

Microsoft's documentation for WM_NOTIFY

...

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.windows7.general, comp.os.ms-windows.programmer.win32

On 2024-11-17, R.Wieser <[email protected]d> wrote:

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.

--
/~\ Charlie Gibbs | Growth for the sake of
\ / <[email protected]d> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.windows7.general, comp.os.ms-windows.programmer.win32

Woodrow,

The dialog in question is, for all intents and purposes, a child of
the dialog that created it

...

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 ?

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.

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 ?

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.windows7.general, comp.os.ms-windows.programmer.win32

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.
--
Fahrradverkehr in Deutschland: http://radwege.udoline.de/
GPG: A245 F153 0636 6E34 E2F3 E1EB 817A B14D 3E7E 482E

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.windows7.general, comp.os.ms-windows.programmer.win32

Udo,

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".

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.

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)