I have a component which is emulating some of the behaviour of a JTree and as part of that I am trying to show tooltip text based on which “node” of the tree the mouse is over. This is achieved by having a tooltip on the component itself with the getToolTipText method being overridden to provide different text based on the location of the mouse.
This works fine outside the docking framework, however, when showing the screen within the framework the text is correctly updated but the location of the tooltip is wrong. The initial tooltip is rendered in the correct location but once the mouse moves to a different node, causing the text to change, it is rendered in a different (incorrect) location.
As far as I can tell this is somewhat related to the GlassPane getting the tooltip text from the underlying component and setting its own tooltip to be that text. I say this as the tooltip is rendered at a point which is at the correct distance into my component but relative instead to the glass pane. This means that if I have my component in the top left of the screen it works fine but when I move it elsewhere the tooltip is still rendered relative to the top left corner.
I was wondering whether this should be achievable or if the framework doesn’t work with this kind of tooltip behaviour? Any insight would be greatly appreciated.
In my test (see below) I could not reproduce the failure. Maybe your “getToolTipText” method is modifying the MouseEvent? Because right now I don’t have any clue how this bug can even happen…
[Edit: If I call “MouseEvent.translate” in the “getToolTipText” method I get a similar failure. How does your method exactly look like?]
import java.awt.BorderLayout;
import java.awt.Color;
import java.awt.event.MouseEvent;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JPanel;
import bibliothek.gui.dock.common.CControl;
import bibliothek.gui.dock.common.DefaultSingleCDockable;
public class Dock03 {
public static void main( String[] args ){
JFrame frame = new JFrame("Test");
frame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
frame.setBounds( 20, 20, 400, 400 );
CControl control = new CControl( frame );
frame.add( control.getContentArea() );
TestDockable dockable = new TestDockable();
control.addDockable( dockable );
dockable.setVisible( true );
frame.setVisible( true );
}
private static class TestDockable extends DefaultSingleCDockable{
public TestDockable(){
super("test", "Test");
JButton button = new JButton("Hallo");
button.setToolTipText( "This is a tooltip" );
add( button, BorderLayout.NORTH );
JPanel panel = new JPanel(){
@Override
public String getToolTipText( MouseEvent event ){
return event.getX() + " " + event.getY();
}
};
panel.setToolTipText( "should not show up" );
panel.setOpaque( true );
panel.setBackground( Color.GREEN );
add( panel );
}
}
}
At the minute I have a very simple getToolTipText method which, as my component extends JTable, simply uses the row index which the mouse is over as shown below. Perhaps the problem is specific to using a table?
@Override
public String getToolTipText(MouseEvent event) {
final Point p = event.getPoint();
final int hitRowIndex = this.rowAtPoint(p);
return "Test " + hitRowIndex;
}```
If you let my example run on your machine, do you see the failure as well or does it not show up? If it does it must be some issue with the version of the framework or the JDK.
The “rowAtPoint” method does not do anything evil. I’ll set up a test with a JTable, don’t know if it will have any effect.
1.0.8? That’s quite old. I would try an update to 1.1.1, or at least 1.1.0. I don’t recall all the bugfixes, but there is a good chance that this was a bug in 1.0.8 and got fixed since then.
Unfortunately I wasn’t able to test this with a newer version as you suggested.
However, I have been able to work around the issue by using MouseListeners to emulate tooltips rather than using tooltips themselves which has solved the issue for me.
