[racket] Problem with tool-tip pop-up

Hi all,

For me on Windows Vista, in DrRacket, the tool-tip pop-up text disappears,
and the pop-up's background is incorrectly cleared, when the mouse cursor
enters the tool-tip text area.

I have the toolbar on the left ('view' -> 'toolbar' -> 'toolbar on left').

I hover the mouse over one of the tools in the toolbar, and after the
tool-tip has popped up, I move the mouse cursor into the tool-tip text
area, and the tool-tip text is removed and the background is reset to some
default(?) value. (Reported as [racket-bug] all/12562: Toolbar tool-tip
issues).

Note that the tool-tip text is now persistently set for that current
DrRacket tab and all new tabs created from the current tab.

I noticed this problem with tool-tips text being cleared started
manifesting in the nightly builds at about the time the running widget
started, well ... running. And I also noticed that the problem was absent
in the nightly builds when the running widget was briefly returned back to
its old (version 5.2) non-animated self.

Can anyone replicate this issue? Or have I messed up my install some how?

This might be some sort of memory leak, or perhaps some sort of race
condition with the order of clearing and painting. But at the least it is a
problem visually.

And the visual problem is exacerbated, when it is combined with tool-tips
not always disappearing when they mouse focus is shifted away from DrRacket
to a frame it has started. i.e. Under some circumstances, a frame created
by DrRacket appears between (in z-order) DrRacket and the (bad) tool-tip,
since tool-tips are always on top.

Tool-tips should time-out after some number of seconds and disappear
regardless. But instead they sometimes hang around when the tool-tip's
owner has lost mouse focus, and are only cleared after the parent receives
focus again.

BTW: The tool-tips not disappearing (corrupted or not) thing seems to be a
Windows (Vista?) thing. I see it with 'system' GUI components too. It might
be due to some GUI events (e.g. mouse focus lost) being held in a queue and
not processed until some (mouse or keyboard) focus is returned back to the
parent.

Cheers,

Kieron.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20120806/97fdf8fe/attachment-0001.html>