Re: [PATCH] user32: on VK_RETURN, send WM_COMMAND to ancestor, not parent.
"Lei Zhang" <thestig(a)google.com> wrote:
I noticed I can no longer install an application which uses the NSIS installer by repeatedly hitting enter until it finished. I did some testing and it looks like for VK_RETURN, we should be sending WM_COMMAND to the ancestor, and not the parent.
Was edit control reparented at some point? Perhaps WM_COMMAND should be sent to an original parent? -- Dmitry.
On Fri, Apr 4, 2008 at 6:24 AM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote:
"Lei Zhang" <thestig(a)google.com> wrote:
I noticed I can no longer install an application which uses the NSIS installer by repeatedly hitting enter until it finished. I did some testing and it looks like for VK_RETURN, we should be sending WM_COMMAND to the ancestor, and not the parent.
Was edit control reparented at some point? Perhaps WM_COMMAND should be sent to an original parent?
-- Dmitry.
The edit control is the child of a dialog box bar, which is in turn the child of another dialog box foo. SetParent() is not involved, if that's what you mean. - Lei
"Lei Zhang" <thestig(a)google.com> wrote:
The edit control is the child of a dialog box bar, which is in turn the child of another dialog box foo. SetParent() is not involved, if that's what you mean.
Seems that's not the case then, from your test it looks more like a WM_COMMAND forwarding from a child dialog to the parent one. -- Dmitry.
On Fri, Apr 4, 2008 at 9:14 AM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote:
"Lei Zhang" <thestig(a)google.com> wrote:
The edit control is the child of a dialog box bar, which is in turn the child of another dialog box foo. SetParent() is not involved, if that's what you mean.
Seems that's not the case then, from your test it looks more like a WM_COMMAND forwarding from a child dialog to the parent one.
-- Dmitry.
I'm pretty sure the parent dialog is getting the WM_COMMAND directly. It is not the case where the child dialog gets a WM_COMMAND, and forwards it to its parent. Running the test on Windows, the child dialog gets two WM_COMMANDS - EN_SETFOCUS and EN_KILLFOCUS. Then the parent dialog gets WM_COMMAND with IDOK. - Lei
On Fri, Apr 4, 2008 at 11:11 AM, Lei Zhang <thestig(a)google.com> wrote:
On Fri, Apr 4, 2008 at 9:14 AM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote:
"Lei Zhang" <thestig(a)google.com> wrote:
The edit control is the child of a dialog box bar, which is in turn the child of another dialog box foo. SetParent() is not involved, if that's what you mean.
Seems that's not the case then, from your test it looks more like a WM_COMMAND forwarding from a child dialog to the parent one.
-- Dmitry.
I'm pretty sure the parent dialog is getting the WM_COMMAND directly. It is not the case where the child dialog gets a WM_COMMAND, and forwards it to its parent.
Running the test on Windows, the child dialog gets two WM_COMMANDS - EN_SETFOCUS and EN_KILLFOCUS. Then the parent dialog gets WM_COMMAND with IDOK.
- Lei
Ah, this is because the child dialog has the DS_CONTROL style. I should test for that and handle it appropriately. - Lei
On Fri, Apr 4, 2008 at 9:55 PM, Lei Zhang <thestig(a)google.com> wrote:
On Fri, Apr 4, 2008 at 11:11 AM, Lei Zhang <thestig(a)google.com> wrote:
On Fri, Apr 4, 2008 at 9:14 AM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote:
"Lei Zhang" <thestig(a)google.com> wrote:
The edit control is the child of a dialog box bar, which is in turn the child of another dialog box foo. SetParent() is not involved, if that's what you mean.
Seems that's not the case then, from your test it looks more like a WM_COMMAND forwarding from a child dialog to the parent one.
-- Dmitry.
I'm pretty sure the parent dialog is getting the WM_COMMAND directly. It is not the case where the child dialog gets a WM_COMMAND, and forwards it to its parent.
Running the test on Windows, the child dialog gets two WM_COMMANDS - EN_SETFOCUS and EN_KILLFOCUS. Then the parent dialog gets WM_COMMAND with IDOK.
- Lei
Ah, this is because the child dialog has the DS_CONTROL style. I should test for that and handle it appropriately.
- Lei
I thought maybe the DS_CONTROL style caused the message to get propagated up, like in DIALOG_FindMsgDestination(). So I did more tests. I removed the DS_CONTROL style, but that didn't change the result of the test. I also tried something more elaborate, where we have a series of dialog windows, each of which contains another dialog window... until the last one which contains the edit control. When I send the edit control the VK_RETURN, the top most dialog window gets the WM_COMMAND with wparam=IDOK. None of the dialog boxes between the edit control and its ancestor gets the WM_COMMAND msg.
"Lei Zhang" <thestig(a)google.com> wrote:
I thought maybe the DS_CONTROL style caused the message to get propagated up, like in DIALOG_FindMsgDestination(). So I did more tests.
I removed the DS_CONTROL style, but that didn't change the result of the test. I also tried something more elaborate, where we have a series of dialog windows, each of which contains another dialog window... until the last one which contains the edit control. When I send the edit control the VK_RETURN, the top most dialog window gets the WM_COMMAND with wparam=IDOK. None of the dialog boxes between the edit control and its ancestor gets the WM_COMMAND msg.
I'd like to see a fully fledged message test for this, with all 'parent' messages logged, and full window tree parent->child1->child2 checked. -- Dmitry.
On Tue, Apr 8, 2008 at 11:27 PM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote:
"Lei Zhang" <thestig(a)google.com> wrote:
I thought maybe the DS_CONTROL style caused the message to get propagated up, like in DIALOG_FindMsgDestination(). So I did more tests.
I removed the DS_CONTROL style, but that didn't change the result of the test. I also tried something more elaborate, where we have a series of dialog windows, each of which contains another dialog window... until the last one which contains the edit control. When I send the edit control the VK_RETURN, the top most dialog window gets the WM_COMMAND with wparam=IDOK. None of the dialog boxes between the edit control and its ancestor gets the WM_COMMAND msg.
I'd like to see a fully fledged message test for this, with all 'parent' messages logged, and full window tree parent->child1->child2 checked.
-- Dmitry.
Nevermind, this patch is wrong. I already sent a patch to unbreak all the dialog problems I caused.
participants (2)
-
Dmitry Timoshkov -
Lei Zhang