FWD » Core Development » User Interface

Tooltips must be contained in an OverlayWindow so that their contents can draw outside of the bounds of the "real" containing window (when needed).

Please see #2837 for details of how this was resolved for combo-box drop-downs. The same approach should be used here.

Although the Swing client does need the overlay window approach, for the web client I think tooltips are an ideal example of a feature which would be best implemented mostly on the javascript side. As noted in #4029, the idea is to move the drawing/event processing to javascript while just synchronizing the state needed to handle this remotely.

The rendering of tooltips is simple, there is no interactive/editing feature and the mouse processing would be much faster without any upcalls. Essentially, we would need to maintain a map of the hover locations to their tooltips, based on the z-order in the 4GL. This state would have to be synchronized.

3821c/13105 solves the problems described in #3981, for Web driver (tooltip for a widget behind another widget, in z-order, must be shown).

There is also another possible problem: OE shows the tooltip regardless of the widget's sensitivity, and also it shows the tooltip for 'the closest widget in z-order on that location, which has a tooltip'. There are issues in Swing about this, as AbstractContainer.findMouseSource will ignore non-sensitive widgets, during the lookup.

We can close this task as of trunk rev 15429 (the changes from #8019), right?

Greg Shah wrote:

We can close this task as of trunk rev 15429 (the changes from #8019), right?

Correct, the requested feature was provided by #8019.