On Fri, Apr 4, 2008 at 9:55 PM, Lei Zhang <[EMAIL PROTECTED]> wrote: > > On Fri, Apr 4, 2008 at 11:11 AM, Lei Zhang <[EMAIL PROTECTED]> wrote: > > > > On Fri, Apr 4, 2008 at 9:14 AM, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote: > > > "Lei Zhang" <[EMAIL PROTECTED]> 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.
