Community
Participate
Working Groups
Build Identifier: 3.6.2M20110210 OBSERVED: * On Windows, a tooltip of type ColumnViewerToolTipSupport respects *neither* monitor bounds nor display bounds. * On Mac, such tooltips *do* respect monitor/display bounds. * ColumnViewerToolTipSupport is a subclass of ToolTip. * ToolTip offers methods to set whether to respect monitor or display bounds -- the default is true. EXPECTED: * That ColumnViewerToolTipSupport would satisfy the contract of its superclass, and respect monitor/display bounds unless specifically requested otherwise. OTHER DETAILS: * Not sure if it matters, but in our case the tooltip was on a CheckBoxTreeViewer. Reproducible: Always Steps to Reproduce: 1. Place a tree viewer cell near the right side of a monitor or display. 2. Hover over the cell. 3. Observe the tooltip appearing on another monitor or partially off the display.
That is not SWT ToolTip, right ? moving to JFace.
(In reply to comment #1) > That is not SWT ToolTip, right ? > moving to JFace. I don't see any platform specific code for this. org.eclipse.jface.window.ToolTip.fixupDisplayBounds( ) method. Is there anything should be done specifically for Windows? Moving back to SWT for comments
(In reply to comment #2) > (In reply to comment #1) > > That is not SWT ToolTip, right ? > > moving to JFace. > I don't see any platform specific code for this. > org.eclipse.jface.window.ToolTip.fixupDisplayBounds( ) method. Is there > anything should be done specifically for Windows? > Moving back to SWT for comments What are you trying to do ? what is the expected/actual results ?
Created attachment 196798 [details] Tooltips in column viewer do not respect monitor bounds We use a CheckBoxTreeViewer as a control in an RCP application. On Mac 10.6, tooltips respect display and monitor bounds. On Windows Vista/7, they do not. This behavior is observed in other tree viewers in Eclipse IDE (3.6.2) on Windows. Actual result: The attachment shows the tooltip problem for the IDE Plug-ins view (docked to the right side of the workbench window). Expected result: The tooltip remains on-screen.
(In reply to comment #4) > Created attachment 196798 [details] > Tooltips in column viewer do not respect monitor bounds That tooltip is a native tooltip provided by the treeview control. You can see the same behaviour with Windows Explorer.
(In reply to comment #5) > That tooltip is a native tooltip provided by the treeview control. You can see > the same behaviour with Windows Explorer. Is it possible to replace that native tooltip? I understand that one of the goals of SWT is to use native controls. But in this case, the native behavior seems more of a limitation than a potentially useful behavior. BTW, does JFace class ColumnViewerToolTipSupport do anything on Windows? The tooltips appear whether an instance is created or not; the ToolTip bounds methods are ignored; and when an instance of a subclass is created, the recommended createViewerToolTipContentArea() sibling does not appear to be called.
(In reply to comment #6) > I understand that one of the goals of SWT is to use native controls. But in > this case, the native behavior seems more of a limitation than a potentially > useful behavior. > > BTW, does JFace class ColumnViewerToolTipSupport do anything on Windows? The > tooltips appear whether an instance is created or not; the ToolTip bounds > methods are ignored; and when an instance of a subclass is created, the > recommended createViewerToolTipContentArea() sibling does not appear to be > called. Now that Indigo is released, could anyone comment on these questions from June? Thanks.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
