Re: [1/3] comctl32: Do not call parent of tool window for tip text

[Ann & Jason Edmeades]

> Sending message to parent in tooltip code 
> probably simply works around toolbar's broken behavior. In this case I

think
> I've identified a line in toolbar.c that fails to properly detect empty

string
> causing not appearing tooltips in Radmin. I'll try to submit another patch

with
> this fix shortly.

Thanks for checking this out - If your new patch makes tooltips work, I
should probably be quiet...

But.. I was looking through my notes of when I was working on this bug,
looking at SPY++ logs from windows and comparing them with
+spy,+message,+msg etc logs from wine.

My notes indicated I was seeing the following sequence (I have hwnds or
whatever spy logs written down):
Tooltip sends toolbar needtextW
Sends to base class tbn_GetInfoTipA which didn't return anything
Sends tbn_GetInfoTipA to its parent which didn't return anything
Tooltip sends baseclass ttn NeedTextA
Which forwards to parent as ttn NeedTextA

My notes and investigations could be wrong, does this tie up with what you
were seing?

Jason

[1/3] comctl32: Do not call parent of tool window for tip text

[Alexander Dorofeyev]

From what I've seen in +tooltips,+toolbar,+msg logs and from running the apps 
in IDA Pro disassembler, it works like follows:

* TOOLTIPS_GetTipText calls TOOLTIPS_GetDispInfoA/W
* TOOLTIPS_GetDispInfoA/W sends TTN_GETDISPINFO(=TTN_NEEDTEXT) notification to 
tool's notify window, which is toolbar's window; tool's id (which is equal to 
toolbar button's commandid) is passed in wparam
* it gets to TOOLBAR_TTGetDispInfo handler

now, what I think really should happen in these apps, is TOOLBAR_TTGetDispInfo 
in its last step should send TTN_GETDISPINFO/TTN_NEEDTEXT to the toolbar's 
notify window and put button's command id (taken from tooltip tool's id) in 
wparam. In both DCPlusPlus and RAdmin this returns a correct tip text. Now the 
problem is, because of bugs in TOOLBAR_TTGetDispInfo, it wasn't sending exactly 
such message. First, because it wasn't putting any meaningful value in wparam 
(fixed by my patch 3/3), second (what I wasn't aware of before you told me of 
RAdmin) in ANSI version it wasn't even getting to that last step (sending 
TTN_GETDISPINFO/TTN_NEEDTEXT) - fixed by 4/3. So then it was returning to 
TOOLTIPS_GetDispInfoA/W which tried to send TTN_GETDISPINFO to the parent with 
tool's id in wparam - note that it's essentially the same thing toolbar will do 
if bugs in it are fixed. So in RAdmin case tooltips control was sort of 
successfully compensating for bugs in toolbar's handler. But, in DCPlusPlus case 
, only after the application already got a wrong TTN_GETDISPINFO notification 
(with wparam = 0) from toobar's handler.

About that message sequence you describe, can you clarify if it's recorded on 
Native or Wine? It looks right for Wine (without my patches applied), but if 
that happened on native, then there may be a problem, because I don't know how 
that could be happening. Conformance test I've written, for example, indicates 
that parent window of tool's notify window doesn't get called by tooltip.

Ann & Jason Edmeades wrote:
> > Sending message to parent in tooltip code 
> > probably simply works around toolbar's broken behavior. In this case I
>
> think
> > I've identified a line in toolbar.c that fails to properly detect empty
>
> string
> > causing not appearing tooltips in Radmin. I'll try to submit another patch
>
> with
> > this fix shortly.
>
> Thanks for checking this out - If your new patch makes tooltips work, I
> should probably be quiet...
>
> But.. I was looking through my notes of when I was working on this bug,
> looking at SPY++ logs from windows and comparing them with
> +spy,+message,+msg etc logs from wine.
>
> My notes indicated I was seeing the following sequence (I have hwnds or
> whatever spy logs written down):
> Tooltip sends toolbar needtextW
> Sends to base class tbn_GetInfoTipA which didn't return anything
> Sends tbn_GetInfoTipA to its parent which didn't return anything
> Tooltip sends baseclass ttn NeedTextA
> Which forwards to parent as ttn NeedTextA
>
> My notes and investigations could be wrong, does this tie up with what you
> were seing?
>
> Jason