Hi all,<br><br>For me on Windows Vista, in DrRacket, the tool-tip pop-up text disappears, and the pop-up&#39;s background is incorrectly cleared, when the mouse cursor enters the tool-tip text area. <br><br>I have the toolbar on the left (&#39;view&#39; -&gt; &#39;toolbar&#39; -&gt; &#39;toolbar on left&#39;). <br>
<br>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).<br>
<br>Note that the tool-tip text is now persistently set for that current DrRacket tab and all new tabs created from the current tab.<br><br>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. <br>
<br>Can anyone replicate this issue? Or have I messed up my install some how?<br><br>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.<br>
<br>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. <br>
<br>Tool-tips should time-out after some number of seconds and disappear regardless. But instead they sometimes hang around when the tool-tip&#39;s owner has lost mouse focus, and are only cleared after the parent receives focus again.<br>
<br>BTW: The tool-tips not disappearing (corrupted or not) thing seems to be a Windows (Vista?) thing. I see it with &#39;system&#39; 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.<br>
<br>Cheers,<br><br>Kieron.<br><br>