Re: comctl32: Make an attempt to update notification handle
Nikolay Sivov <nsivov(a)codeweavers.com> wrote:
+ case WM_WINDOWPOSCHANGING: + { + HWND parent = GetParent(hwnd); + if (parent) infoPtr->hwndNotify = parent; + return DefWindowProcW(hwnd, uMsg, wParam, lParam); + }
What if an application subclasses tab and doesn't pass WM_WINDOWPOSCHANGING to the original proc? Why not just call GetParent() every time when a notification is being sent? -- Dmitry.
On 3/25/2013 07:24, Dmitry Timoshkov wrote:
Nikolay Sivov <nsivov(a)codeweavers.com> wrote:
+ case WM_WINDOWPOSCHANGING: + { + HWND parent = GetParent(hwnd); + if (parent) infoPtr->hwndNotify = parent; + return DefWindowProcW(hwnd, uMsg, wParam, lParam); + } What if an application subclasses tab and doesn't pass WM_WINDOWPOSCHANGING to the original proc? Then it will fail just like it does currently, and will work for the rest of the applications. Why not just call GetParent() every time when a notification is being sent? Because it won't work if you create a control without WS_CHILD.
Nikolay Sivov <nsivov(a)codeweavers.com> wrote:
+ case WM_WINDOWPOSCHANGING: + { + HWND parent = GetParent(hwnd); + if (parent) infoPtr->hwndNotify = parent; + return DefWindowProcW(hwnd, uMsg, wParam, lParam); + } What if an application subclasses tab and doesn't pass WM_WINDOWPOSCHANGING to the original proc? Then it will fail just like it does currently, and will work for the rest of the applications.
Is it really supposed to fail?
Why not just call GetParent() every time when a notification is being sent? Because it won't work if you create a control without WS_CHILD.
How is that different from the WM_WINDOWPOSCHANGING handler? -- Dmitry.
On 3/25/2013 07:34, Dmitry Timoshkov wrote:
Nikolay Sivov <nsivov(a)codeweavers.com> wrote:
+ case WM_WINDOWPOSCHANGING: + { + HWND parent = GetParent(hwnd); + if (parent) infoPtr->hwndNotify = parent; + return DefWindowProcW(hwnd, uMsg, wParam, lParam); + } What if an application subclasses tab and doesn't pass WM_WINDOWPOSCHANGING to the original proc? Then it will fail just like it does currently, and will work for the rest of the applications. Is it really supposed to fail? That's a different problem.
Why not just call GetParent() every time when a notification is being sent? Because it won't work if you create a control without WS_CHILD. How is that different from the WM_WINDOWPOSCHANGING handler? How what is different? There's a check for null parent as you can see.
Nikolay Sivov <nsivov(a)codeweavers.com> wrote:
+ case WM_WINDOWPOSCHANGING: + { + HWND parent = GetParent(hwnd); + if (parent) infoPtr->hwndNotify = parent; + return DefWindowProcW(hwnd, uMsg, wParam, lParam); + } What if an application subclasses tab and doesn't pass WM_WINDOWPOSCHANGING to the original proc? Then it will fail just like it does currently, and will work for the rest of the applications. Is it really supposed to fail? That's a different problem.
No, it's the same problem of not tested behaviour.
Why not just call GetParent() every time when a notification is being sent? Because it won't work if you create a control without WS_CHILD. How is that different from the WM_WINDOWPOSCHANGING handler? How what is different? There's a check for null parent as you can see.
Why the same can't be done at the time a notification needs to be sent? There are many places (starting from user32/WM_PARENTNOTIFY) which send notifications that way, what's so special about tab control? -- Dmitry.
On 3/25/2013 07:48, Dmitry Timoshkov wrote:
Why not just call GetParent() every time when a notification is being sent?
Because it won't work if you create a control without WS_CHILD. How is that different from the WM_WINDOWPOSCHANGING handler? How what is different? There's a check for null parent as you can see. Why the same can't be done at the time a notification needs to be sent? There are many places (starting from user32/WM_PARENTNOTIFY) which send notifications that way, what's so special about tab control? Unfortunately it's more complicated than that. For example notifications sent after TCM_SETCURFOCUS are delivered to original window, but if you do any mouse interaction it appears to notify new parent. So SetParent() leaves it in a kind of broken state.
So we can't always use parent window, but for some notification cases valid GetParent() value should be used as in examples you mentioned. Is there any reliable way to test send mouse messages? Cause it looks like if I send WM_LBUTTONDOWN directly it doesn't trigger tab selection code on windows, but works in wine. Thanks for review.
2013/3/26 Nikolay Sivov <nsivov(a)codeweavers.com>:
Is there any reliable way to test send mouse messages? Cause it looks like if I send WM_LBUTTONDOWN directly it doesn't trigger tab selection code on windows, but works in wine.
Do you want to figure out the correct sequence of messages or write tests for wine's test suite? Either way, it's a good idea to start with winetricks comctl32. After that WINEDEBUG=+message gives you all information you may need. First thing you may want to check is if there's a modal message loop involved. Run the application with +message and click. If the last line in console is '...WM_LBUTTONDOWN returned', you're looking at a message loop. If it's WM_LBUTTONUP, it's probably standard handling. Keep in mind that some window styles may affect message handling (e.g. treeview handles mouse messages differently when TVS_DISABLEDRAGDROP is specified) If you want to write tests, you may be able to use SendMessage. It's much less work than SendInput or mouse_event, and is more reliable as BlockInput is not implemented. I had some degree of success with SendMessage when testing ListView and Treeview, but my tests never made it into git. Also some message handlers use mouse coordinates from lParam, while others seem to use either GetCursorPos or GetMessagePos, so setting cursor position may be necessary. Regards, Daniel
On 3/27/2013 00:10, Daniel Jeliński wrote:
2013/3/26 Nikolay Sivov <nsivov(a)codeweavers.com>:
Is there any reliable way to test send mouse messages? Cause it looks like if I send WM_LBUTTONDOWN directly it doesn't trigger tab selection code on windows, but works in wine. Do you want to figure out the correct sequence of messages or write tests for wine's test suite? I need a test that actually works. Either way, it's a good idea to start with winetricks comctl32. After that WINEDEBUG=+message gives you all information you may need. That's a really questionable thing to do cause you'll be looking at native module internals, tracing what it does. I think it should be avoided. Also some message handlers use mouse coordinates from lParam, while others seem to use either GetCursorPos or GetMessagePos, so setting cursor position may be necessary. I didn't think about actually positioning cursor, that could help, thanks.
Regards, Daniel
participants (3)
-
Daniel Jeliński -
Dmitry Timoshkov -
Nikolay Sivov