Always manage custom tooltip in Tree in Win32 #62 #2137
Conversation
The commit allows to always create custom tooltip handles in the Tree while creating items. The is necessary to always fit the tooltips inside a single monitor as there can be freezing problems while using per-monitor awareness if the tooltip spans over multiple monitors. contributes to eclipse-platform#62 and eclipse-platform#127
There was a problem hiding this comment.
Looks like a nice simplification of the tooltip handling. But I have to admit that I do not understand why it works. Without these changes, isCustomToolTip() never yields "false" for me, even for the problematic breakpoints view. Please see the detailed comments for that.
| boolean isCustomToolTip () { | ||
| return hooks (SWT.MeasureItem); | ||
| } |
There was a problem hiding this comment.
Can you please explain why this is not relevant anymore (or why it was relevant before)? In my understanding, it validates whether a MeasureItem listener was registered, but I have to admit that I do not understand the reasons. What will be the effect in case there was a tree for which such a listener was not registered and thus tool tips were not custom? I set a breakpoint for the case the !isCustomToolTip() and triggered tool tips in several Trees, but it was never triggered.
| @@ -2200,7 +2200,7 @@ void createItem (TreeItem item, long hParent, long hInsertAfter, long hItem) { | |||
| } | |||
| } | |||
| } | |||
|
|
|||
| createItemToolTips (); | |||
There was a problem hiding this comment.
Why do we need this additional creation here?
This has some effect that I do no understand: without this addition, I do not face any calls to isCustomToolTip() that yields "false", even for the breakpoints view the original issue is about.
| String[] strings = item [0].strings; | ||
| if (strings != null) text = strings [index [0]]; | ||
| } | ||
| //TEMPORARY CODE |
There was a problem hiding this comment.
Nice to get temporary removed from > 15 years ago removed :-)
| @@ -211,7 +211,7 @@ void _addListener (int eventType, Listener listener) { | |||
| case SWT.PaintItem: { | |||
| customDraw = true; | |||
| style |= SWT.DOUBLE_BUFFERED; | |||
| if (isCustomToolTip ()) createItemToolTips (); | |||
| createItemToolTips (); | |||
There was a problem hiding this comment.
There are three (?) places where createItemToolTips() is called. Can't we do it once e.g. in createHandle or doesn't that work?
| return new LRESULT (OS.CDRF_NOTIFYPOSTPAINT | OS.CDRF_NEWFONT); | ||
| } | ||
| break; | ||
| //TEMPORARY CODE |
There was a problem hiding this comment.
Would be interesting to understand what this does. If everything works fine, we could just remove that, right?
The PR contributes to the creation of custom tooltip handles in the Tree while creating items. It is a necessity to always have custom tooltips as it needs to be fit inside a single monitor since there can be freezing problems while using per-monitor awareness if the tooltip spans over multiple monitors.
contributes to
#62 and #127