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.

  xxxxx@xxxxx   2005-05-25 14:37:27 GMT

Call pack() before setBounds():

		// 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);

+		dialog.pack();

		// 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();
  xxxxx@xxxxx   2003-05-22

Reproducible as described on Windows 2000 using 1.4.1 and 1.4.2b24.  This problem did not occur with 1.4 or 1.3.1.
  xxxxx@xxxxx   2003-05-22

As suggested, the mechanism for updating the Dialog's GraphicsConfiguration is not being triggered if the Dialog first appears on a device with negative coordinates.  A workaround which avoids the problem is to call pack() on the Dialog before calling setBounds().  This creates the native resources for the Dialog.  In this case when setBounds() is called, the Dialog's GraphicsConfiguration is updated and the app behaves as expected.

Special thanks to the submitter for a very well written bug report. =)
  xxxxx@xxxxx   2003-05-22

The submitter reports that for resizable frames, one must call:
pack();
setResizable(false);
setResizable(true);
setBounds(...);
  xxxxx@xxxxx   2003-06-03

If we create a window with a specific GraphicsConfig, and then move it with setLocation() or setBounds() to another one before its peer has been created, then calling Window.getGraphicsConfig() returns wrong config. That may lead to some problems like wrong-placed tooltips. It is caused by calling super.displayChanged() in WWindowPeer.displayChanged() regardless of whether GraphicsDevice was really changed, or not. We should track this issue, when the window is shown.


  xxxxx@xxxxx   2005-05-24 06:52:10 GMT

It is worth noting the performance problem/fix here as well (as reported in duplicate bug 6231735); if we create rendering resources one one GraphicsDevice that for peers that are actually on a different device, then performance can be pretty awful as we cause the system to copy from the video memory of one device to another (causing all kinds of performance problems such as reading from VRAM and copying the pixels up the bus, through the CPU, and down the bus to the other device).  Fixing the problem of tooltips for this bug report also fixes the performance problem because we are now creating the rendering resources on the correct device when the peer is shown.

The fix here is to update the graphicsConfig object appropriately in the show() method of the peer to ensure that it is correct for the device where the peer is appearing.

  xxxxx@xxxxx   2005-05-25 14:37:27 GMT

There is also a problem when the application spans across
two monitors, one monitor's GraphicsConfiguration is own by
all components.  Therefore the tooltips for the components
that span to the right monitor will apear on the left
monitor.  Bounded by the GC.  There must be a way for each
component to own it's own GC, not just get it from the
parent which is the case in ToolTipManager.

The workaround will not fix this problem.

? from 4924243 :
frame.pack();
frame.setBounds(bounds);
frame.setLocation(new Point(0, 0));
frame.setBounds(bounds);

This fix not working please can you suggest any other method for solving this problem.
Still we are facing for tooltip but popup menu working fine .
Both the component extends the JComponent Class .

What do you mean by "This fix not working"? As far as I know this bug is fixed in 6.0, so you can download 6.0-beta and look if the problem still appears.

I mean that i hava try out it but still facing this problem on our application.
now i am going to looking on 6.0 -beta  and let you know later.

Good very Good...................

can u tell me how to give tooltip in Awt .i knw in Swing.

AWT does not provide any API for tooltips, use Swing ones

I am still seeing this bug under Java 1.5 Update 7 when running an applet in IE.  It works ok running the applet in Mozilla. 

Update: The bug also still occurs under Java 1.5 Update 9 when running an applet in IE

For those who still think they're seeing a problem with this, bug # 4825949  is similar to this one and is still open.

When an application spans multiple monitors, the tool tips are shown on the monitor that shows the largest part of a component.  Instead, tool tips should be displayed on the monitor where the mouse pointer is.

To reproduce, simply start this small application.  Move it across the monitor edge, but keep the largest part on the first monitor.  All tool tips are now displayed on the 1st monitor, whereas you would expect the tool tips of the right most buttons (which are on the 2nd monitor) to appear on the 2nd monitor.

Tested with 1.6.0_06, 1.6.0_10b and 1.5.0_15.

public class TestTooltips {
  public static void main( String[] args ) {
    EventQueue.invokeLater( new Runnable() {
      public void run() {
        JFrame frame = new JFrame();
        frame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
        Container content = frame.getContentPane();
        content.setLayout( new BorderLayout() );
        JToolBar tb = new JToolBar();

        for ( int i = 0; i < 20; i++ ) {
          tb.add( createAction() );
        }

        content.add( tb, BorderLayout.CENTER );
        frame.pack();
        frame.setLocationRelativeTo( null );
        frame.setVisible( true );
      }
    } );
  }

  private static AbstractAction createAction() {
    AbstractAction action = new AbstractAction() { public void actionPerformed( ActionEvent e ) {} };
    action.putValue( Action.SHORT_DESCRIPTION, "Tooltip" );
    return action;
  }
}