comctl32: Make an attempt to update notification handle
nsivov at codeweavers.com
Tue Mar 26 10:18:53 CDT 2013
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.
More information about the wine-devel