comctl32: Make an attempt to update notification handle

Nikolay Sivov nsivov at
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 mailing list