Name: rmT116609 Date: 05/22/2003


FULL PRODUCT VERSION :
java version "1.4.2-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-beta-b19)
Java HotSpot(TM) Client VM (build 1.4.2-beta-b19, mixed mode)

java version "1.4.1_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06)
Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode)


FULL OS VERSION :
Windows XP Version 5.1.2600

EXTRA RELEVANT SYSTEM CONFIGURATION :
The problem occurs with XP running with certain multiple monitor configurations.

The easiest multiple monitor setup to test with, is using a laptop with dual monitor support which has an external monitor hooked up to it where the combined screens of the LCD laptop monitor and the external monitor are in use.

The external monitor should be on the left hand side of the laptop, and the windows XP display properties should be set up so that "monitor 1" (the laptop lcd) is on the right of "monitor 2".

A DESCRIPTION OF THE PROBLEM :
Basically the problem occurs with dialog with buttons that have been added using Action classes.

If the window is initially displayed on the non-primary display (the LHS of the above setup), then tooltips for the buttons are displayed on the far left of the right hand side (primary) display. The problem goes away once the dialog is moved with the mouse to the right hand display and then back to the left hand display.

I've had a look at the code for ToolTipManager, and in showTipWindow(..) the bounds used to restrain the tool tip position are obtained using :

Rectangle sBounds = insideComponent.getGraphicsConfiguration(). getBounds();

Unfortunately, this gives the bounds of the primary display at this point in time, rather than the bounds of the left hand display in which the dialog has been displayed.


I think what is happening, is that when a Window is initially displayed on the non-primary screen, the window.getGraphicsConfiguration() is returning the default GraphicsConfiguration, and this is not updated until the window is
moved back to the primary display and away from it again.

Also I meant to mention in the bug report, that this problem does not occur when tested on an NT PC with a Matrox dual head graphics card connected to two monitors. With this setup, the combined workspace of the two monitors is treated as a single graphics configuration.

I've included a simple code example that will demonstrate the problem below.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the simple java code included below.

java -cp . testToolTips

This displays a dialog with some text and a simple button on the left hand display.

Hover you mouse over the button.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I expect the tool tip to be displayed near the button it belongs to, which is displayed on the left hand display (external monitor.)
ACTUAL -
The tool tip appears on the left hand edge of the primary (righthand/laptop) display.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javax.swing.*;
import java.awt.*;
import java.awt.event.*;

public class testToolTips
{

// Create action class for button.
protected static Action action = new AbstractAction("Press this button to exit..",null)
{
// javadoc from java.awt.event.ActionListener
public void actionPerformed(ActionEvent ae)
{
System.out.println("Button pressed, so we are exiting....");
System.exit(0);
}
};

public static void main(String[] args)
{

Rectangle virtualBounds = getScreenBounds();

System.out.println("Hello there");

// Set windows look and feel.
try
{
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
}
catch (Throwable t)
{
}

// create toolBar
JToolBar toolBar = new JToolBar();

// add button to tool bar
JButton button = toolBar.add(action);

// set tooltip text on button
button.setToolTipText((String)action.getValue(Action.NAME));

// create text area
JTextArea text = new JTextArea("Hello! Check out the tool tip and see \nif it is drawn on the on primary display.");

// create dialog and add the tool bar and text
JDialog dialog = new JDialog();
dialog.getContentPane().add(toolBar, BorderLayout.NORTH);
dialog.getContentPane().add(text, BorderLayout.CENTER);

// position on dialog on the left hand display (assuming 2 screens)
dialog.setBounds(virtualBounds.x + virtualBounds.width/4, virtualBounds.y + virtualBounds.height/4,virtualBounds.width/4,virtualBounds.height/4);

// display the dialog.
dialog.show();

                // This prints out the wrong bounds for where the dialog is located, and this is the exactCode used in ToolTipManager.showTipWindow()
System.out.println(" dialogs graphics config bounds are " + dialog.getGraphicsConfiguration().getBounds());

}



static public Rectangle getScreenBounds()
{
Rectangle virtualBounds = new Rectangle();
GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
GraphicsDevice[] gs = ge.getScreenDevices();
for (int j = 0; j < gs.length; j++) {
GraphicsDevice gd = gs[j];
GraphicsConfiguration[] gc = gd.getConfigurations();
for (int i=0; i < gc.length; i++) {
virtualBounds = virtualBounds.union(gc[i].getBounds());
}
}
System.out.println("Virtual bounds are " + virtualBounds);
return virtualBounds;
}

}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
It basically makes our software look unprofessional when used with this particular monitor set up.
(Review ID: 186322)
======================================================================

Also note that this problem causes a severe performance penalty, as reported in duplicate bug 6231735.

###@###.### 2005-05-25 14:37:27 GMT