On 20.02.2017 22:17, Eric Kohl wrote:
Signed-off-by: Eric Kohl eric.kohl@t-online.de
dlls/comctl32/toolbar.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/dlls/comctl32/toolbar.c b/dlls/comctl32/toolbar.c index 784745c..bb53d66 100644 --- a/dlls/comctl32/toolbar.c +++ b/dlls/comctl32/toolbar.c @@ -1690,6 +1690,7 @@ TOOLBAR_LayoutToolbar(TOOLBAR_INFO *infoPtr) if (btnPtr->fsState & TBSTATE_HIDDEN) { SetRectEmpty (&btnPtr->rect);
}TOOLBAR_TooltipSetRect(infoPtr, btnPtr); continue;
Hi, Eric.
What are symptoms of that? I'd guess it's causing tooltips to appear when they shouldn't, or tooltips from one button to appear for another.
Do you have an demo application for that or any easy way to reproduce?
On 20.02.2017 20:24 Nikolay wrote:
Hi, Eric.
What are symptoms of that? I'd guess it's causing tooltips to appear when they shouldn't, or tooltips from one button to appear for another.
Do you have an demo application for that or any easy way to reproduce?
Hi, Nikolay!
One symptom is that tooltips appear on the wrong button. When you hide a button from the toolbar, the next button appears in the same location as the now hidden button but it does not show its own tooltip but the tooltip of the hidden button.
Unfortunately I do not know of a simple way to reproduce this in Wine, but it is pretty obvious when you look at the TOOLBAR_LayoutToolbar() function: TOOLBAR_TooltipSetRect() is called for all visible buttons after their proper location has been calculated. The call to TOOLBAR_TooltipSetRect() updates the position and size of the tooltip. But the tooltip rectangle is not updated for hidden toolbar buttons. The patch fixes this issue.
I have seen this bug in the new ReactOS device manager, that shows and hides toolbar buttons depending on the selected treeview item (root, class or device item). When you select a device item first and select a class or root item next, some buttons are hidden. The single remaining button shows the wrong tooltip because it is actually the tooltip of one of the hidden buttons.
I already fixed this in the ReactOS source tree. You need to get a revision before r73853 to see this bug.
Regards Eric