SetToolTip() can never change a tooltip unless HideToolTip() is called first.

[stippi]

GetToolTip() will first return fVisibleToolTip before returning fToolTip. fVisibleToolTip is only reset from within HideToolTip() which in turn is never invoked internally. SetToolTip() will not affect fVisibleToolTip, and so the second and later calls to SetToolTip() with never manage to change the displayed tool tip. I am also not sure why no reference counting is needed for fVisibleToolTip. I can probably fix the problem myself if the original implementors leave enlightening comments... :-)

[axeld]

Reference counting is needed because the BView is not the sole owner of the tip, and since showing/hiding it works asynchronously via messaging.

The idea was that you need to subclass BToolTip if you want to have tool tips that change while they are shown - this is because you could otherwise not prevent the tip view from flickering, ie. you would need to remove its current view, and add the new one.

In other words, changing the BToolTip is usually not what you should do, if you are just displaying text anyway. If you are using the "const char*" version of SetToolTip(), it should actually change the text on screen directly.

If you manage to change the views without flicker, I wouldn't mind allowing to change the BToolTip object that is currently being shown on the fly.

Hope that counts as enlightening :-)

[stippi]

I think you don't understand, yet, what I am saying is that you can't at the moment call SetToolTip(const char*) a second time with a different text, no matter if the tool tip is already showing or not showing at the moment after the mouse moved. Are you saying that the current usage of fVisibleToolTip is really meant to prevent this, even though fVisibleToolTip is never reset when the tool tip hides because the mouse moves?

And with regards to reference counting, I said it is *not* used for fVisibleToolTip, and I was wondering why it isn't.

[axeld]

Sorry, I'm currently sick, and apparently I am not that accurate when I am.

The SetToolTip(const char*) version should update the text directly, if that doesn't happen (there definitely is some locking missing), it has nothing to do with fVisibleToolTip, as that SetToolTip() version doesn't care about it.

In any case, the fVisibleToolTip stuff looks broken to me, too.

[axeld]

Added a temporary work-around in hrev37095; the ticket should stay open, anyway, until this is fixed for real.

[axeld]

Fixed in hrev44075.

I actually could not reproduce the original problem, though, at least not after removing my work-around for the bug; I added a tool tip to the Tracker status window, and that works nicely now, and I've also improved the ToolTipTest application to include the problematic cases.