the following program show evidence that a popup menu is
not cleared properly if the action on the popup was bringing
a JOptionPane to display a message.
The following test must be performed several times
to see the problem. On my platform, NT4 and SP3
occurs after max 5 tests.

// Author : Bruno Coudoin
//
// Show evidence that the popup is not refreshed properly under a joptionpane
// Note that if the frame is smaller and the popup goes beyond its limit, then 
// the problem do not appear

import javax.swing.*;
import java.util.*;
import java.awt.*;
import java.awt.event.*;

public class refreshBug extends JPanel implements ActionListener {
    JPopupMenu _jPopupMenu = new JPopupMenu();

    public void init() {
	JMenuItem menuItem;
	JButton jb = new JButton("Bring the popup here and select an item");

	this.add(jb, BorderLayout.CENTER);

	for(int i=1; i<10; i++) {
	    menuItem = new JMenuItem("Item "+i);
	    menuItem.addActionListener(this);
	    _jPopupMenu.add(menuItem);
	}

	MouseListener ml = new MouseAdapter() {
	    public void mouseReleased(MouseEvent e) {
		if(e.isPopupTrigger()) {
			_jPopupMenu.show(e.getComponent(),
					 e.getX(), e.getY());
		}
	    }
	};
	this.addMouseListener(ml);

	jb.addMouseListener(ml);

    }

    // An action is requested by the user    
    public void actionPerformed(java.awt.event.ActionEvent e) {

	JOptionPane.showMessageDialog(this,
				      "Check if there is some popup left under me\n"+
				      "if not, retry and let the popup appear where i am",
				      "WARNING",
				      JOptionPane.WARNING_MESSAGE);

	// Even this don't work
	_jPopupMenu.setVisible(false);
    }

    // Main
    public static void main(String[] args) {
	refreshBug applet = new refreshBug();
	JFrame frame = new JFrame();

	frame.addWindowListener(new WindowAdapter() {
	    public void windowClosing(WindowEvent e) {
		System.exit(0);
	    }
	});

	frame.setTitle("Popup refresh bug");
	frame.getContentPane().add(applet, BorderLayout.CENTER);
	applet.init();
	frame.setSize(400,400);
	Dimension d = Toolkit.getDefaultToolkit().getScreenSize();
	frame.setLocation((d.width - frame.getSize().width) / 2, (d.height - frame.getSize().height) / 2);
	frame.setVisible(true);
    }

}
(Review ID: 41943)
======================================================================




This problem occurs in NT 4.0 sp3, Win95, Win98
This problem occurs in JDK1.2, JDK1.2.1, and EA JDK1.2.2 (was
renumbered from JDK-1.2.1-K, native threads, symcjit )

This problem has been previously reported as bug #4189244,
but this example reproduces the problem more reliably.

When a JMenuItem's ActionListener displays a dialog box which
obscures some of the menu, then the underlying component does not
properly repaint when the dialog box is dismissed.  The full or
partial image of the popped up menus remains visible.

This happens for either modal or non-modal dialog boxes, but does
not happen for obscuring Frames.


The following code will reproduce the problem.

The paint routine has been deliberately slowed down so that
the problem will reproduce itself every time.  It can be seen
that the repaint of the underlying panel occurs while the dialog
box is being displayed.  The correct areas of the panel obscured
by the popup menus are repainting, but the screen is not being
updated.  When the Dialog box is closed by clicking on the button,
the underlying panel does not repaint, because it thinks that the
screen is up to date.

Two of the three menu choices will reproduce the problem:

1) When the dialog box completely obscures the parent frame
2) When the dialog box partially obscures the menu bar.

In the third case, when the menu bar is completely unobscured,
but the panel is partially obscured, there is no bug.

If double buffering is turned off, the bug does not appear.

This does not appear to be a JMenu bug per se, but a general 
java.awt.Component paint problem ( w. Double buffering )
because this situation can be reproduced in another way:

1) In a swing application, bring up a print dialog.
2) Move the dialog so that it partially overlaps the main frame
3) Now bring up the "properties" dialog from the print dialog
   It should overlap the print dialog and the application frame.
4) Close the dialogs and the image of the print dialog will remain
   on the swing application where the print dialog was obscured
   by the properties dialog.



---------------  MenuRedrawBug.java --------------
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.event.*;

class TestPanel extends JPanel
    {
    int id;
    public TestPanel( int i )
        {
        super();
        id = i;
        }
    public void paint(Graphics g)
        {
        try
            {
            System.out.print("paint " + id);
            Thread.sleep(500);
            }
        catch ( Throwable t )
            {}
        super.paint(g);
        System.out.println(" .....done");
        }
    }

class TestDialog extends JDialog
    {
	JPanel containerPanel = new JPanel();
	Window parent;
	public TestDialog( Frame f)
    	{
    	super(f);
    	parent = f;
    	myInit();
    	}
    public TestDialog( Frame f, boolean b)
    	{
    	super(f,b);
    	parent = f;
    	myInit();
    	}
    private void myInit()
        {
        JButton closeButton = new JButton("Click to close Dialog");
        containerPanel.setLayout(new BorderLayout());
        containerPanel.add( BorderLayout.CENTER, closeButton);
        closeButton.addActionListener( new ActionListener()
            {
            public void actionPerformed( ActionEvent e )
                {
                TestDialog.this.setVisible(false);
                TestDialog.this.dispose();
                }
            });
    	getContentPane().add(containerPanel);
        }
    }

public class MenuRedrawBug extends JFrame
    {
	public MenuRedrawBug()
    	{
    	super();
        setTitle("MenuRedrawBug");
        addWindowListener(new WindowAdapter()
            {
            public void windowClosing(WindowEvent e)
                {
                System.exit(0);
                }
            });
        myInit();
        }

    private void myInit()
        {
        JMenuBar menuBar;
        JMenu menu, submenu;
        JMenuItem menuItem;

        Container contentPane = getContentPane();
        contentPane.setLayout(new GridLayout(1,5));
        JPanel p;
        p = new TestPanel(1);
        p.setBackground(Color.red);
        contentPane.add( p );
        p = new TestPanel(2);
        p.setBackground(Color.white);
        contentPane.add( p );
        p = new TestPanel(3);
        p.setBackground(Color.green);
        contentPane.add( p );
        p = new TestPanel(4);
        p.setBackground(Color.yellow);
        contentPane.add( p );
        p = new TestPanel(5);
        p.setBackground(Color. customer );
        contentPane.add( p );

        //Create the menu bar.
        menuBar = new JMenuBar();
        setJMenuBar(menuBar);
        menu = new JMenu("Show Bug");
        menuBar.add(menu);
        submenu = new JMenu("Bug submenu");
        menu.add(submenu);
        menuItem = new JMenuItem("Show completely overlapping dialog");
        menuItem.addActionListener( new ActionListener()
            {
            public void actionPerformed(ActionEvent e)
                {
                showDialogWithOffset(-10,-10);
                }
            });
        submenu.add(menuItem);

        menuItem = new JMenuItem("Show partially overlapping dialog (no bug)");
        menuItem.addActionListener( new ActionListener()
            {
            public void actionPerformed(ActionEvent e)
                {
                showDialogWithOffset(100,60 );
                }
            });
        submenu.add(menuItem);


        menuItem = new JMenuItem("Show partially overlapping dialog (bug)");
        menuItem.addActionListener( new ActionListener()
            {
            public void actionPerformed(ActionEvent e)
                {
                showDialogWithOffset(60,0 );
                }
            });
        submenu.add(menuItem);

        }

    public void showDialogWithOffset ( int xoffset, int yoffset )
        {
		TestDialog window = new TestDialog(this);
		Dimension size = getSize();
		Point location = getLocation();
		// make dialog a little bigger than the JFrame
		window.setSize ( size.width + 30, size.height + 30 );
		location.translate ( xoffset, yoffset );
		window.setLocation ( location );
		window.show();
        }

    public static void main(String[] args)
        {
        MenuRedrawBug window = new MenuRedrawBug();
        window.setSize(450, 260);
        window.setVisible(true);
        }
    }

------------------------ end MenuRedrawBug.java --------------
======================================================================




I have a simple Swing application with a menu bar and 2 
scrollable lists in a JSplitPane.  Some of the menu functions 
bring up standard dialogs (JOptionPane dialogs).  The problem is
that after a dialog is dismissed, the app's main window does not
get repainted.  The menu still appears to be pulled down, even 
though it is not active.

I will gladly provide source code, please contact me by email.
It's too much to include here.

java -version output:
java version "1.2.1"
Classic VM (build JDK-1.2.1-A, native threads)

java -fullversion output:
java fullversion "JDK-1.2.1-A"
(Review ID: 63113)
======================================================================




I open a dialog through a menu item in which the dialog 
completely covers the menu items list.  When the dialog is 
closed, the menu items are still there (it missed a repaint).
(Review ID: 84133)
======================================================================




On some Windows 95 systems using JDK 1.2, the Swing components do not function properly. Wherever the cursor is used, the screen components do not refresh properly. For instance, GUI components, such as a menu selection, remain on the screen after the menu collapses. The screen gets more and more corrupted as more cursor/mouse actions are performed.  This has been seen on a number of Windows 95 systems as witnessed in some of the java newsgroups such as comp.lang.java.gui.

It has also been reported on multi-processor NT systems. I discovered the problem when using a couple of JAVA IDEs that were written in Swing. The IDEs (NetBeans DeveloperX2 2.1 and Jasupremo 2.0) are not usable due to these problems. Jasupremo 2.0 is more lightweight, and you can use it to easily reproduce the problem.  It is available from www.tucows.com. Please investigate this problem. If people continue to have problems (functional and performance) with Swing, it will likely be rejected by developers.  

Since not all Windows 95 systems witness the problem, I will give you a brief list of common software that is on both of my Windows 95 systems that exhibit the problem:   Visual Basic 4.0 and 5.0, Lotus Notes 4.5, Visual Age for Java, and the  xxxxx  AS/400 Client/Access product. The two systems have different display drivers (ATI Rage and Matrox Millenium), and so I don't think that's the problem. I run with large fonts, 1024*768 resolution, and 16 or 24 bit color. Everything else (Notes apps, Visual Basic apps,etc) works fine on the PCs. It's just Swing applications that exhibit the problem.
(Review ID: 53626)
======================================================================




Hi,

I've got the following problem with my file menu: When I choose "open" from the menu (see source below), the fileDialog pops up (just like I intended). If it pops up on the spot where the menu was displayed (thus fully covering this spot) and I press cancel, the menu is still displayed when the dialog is closed. The menu does not respond to mouse clicks any more and it disappears when I start clicking on the menu name ("File").

OK here's the source of my file (nevermind the classname :) 

import javax.swing.*;
import java.awt.event.*;
import java.awt.*;
import java.io.*;

public class AlienManager extends JFrame
{
	JMenuBar menubar = new JMenuBar();
	JMenu fileMenu = new JMenu("File");
	JMenuItem newItem = new JMenuItem("New");
	JMenuItem openItem = new JMenuItem("Open");
	JMenuItem saveItem = new JMenuItem("Save");
	JMenuItem saveasItem = new JMenuItem("Save as");
	JMenuItem exitItem = new JMenuItem("Exit");
	JTable aliensTable = new JTable();

	//Create a file chooser
	final JFileChooser fc = new JFileChooser();
	
	File currentFile = null;
	
	public AlienManager()
	{
		Container pane= getContentPane();
		buildMenu();
		setSize(400,300);
		addWindowListener(new WindowAdapter() {
			public void windowClosing(WindowEvent e) 
			{
				closeApplication();
			}
		});
		pane.add("Center", new JScrollPane(aliensTable));
	}
	
	void buildMenu()
	{
		newItem.addActionListener(new AbstractAction() {
			public void actionPerformed(ActionEvent al)
			{
			}
		});
		openItem.addActionListener(new AbstractAction() {
			public void actionPerformed(ActionEvent al)
			{
				//In response to a button click:
				fc.setDialogType(JFileChooser.OPEN_DIALOG);
				int returnVal = fc.showOpenDialog(AlienManager.this);
				if (returnVal == JFileChooser.APPROVE_OPTION) 
				{
        				currentFile = fc.getSelectedFile();
        			}
			}
		});
		saveItem.addActionListener(new AbstractAction() {
			public void actionPerformed(ActionEvent al)
			{
				// save currentFile
			}
		});
		saveasItem.addActionListener(new AbstractAction() {
			public void actionPerformed(ActionEvent al)
			{
				// select a new value for currentFile
				fc.setDialogType(JFileChooser.SAVE_DIALOG);
				int returnVal = fc.showSaveDialog(AlienManager.this);
				if (returnVal == JFileChooser.APPROVE_OPTION) 
				{
        				currentFile = fc.getSelectedFile();
        			}
			}
		});
		exitItem.addActionListener(new AbstractAction() {
			public void actionPerformed(ActionEvent al)
			{
				closeApplication();
			}
		});
		fileMenu.add(newItem);
		fileMenu.add(openItem);
		fileMenu.add(saveItem);
		fileMenu.add(saveasItem);
		fileMenu.add(exitItem);
		menubar.add(fileMenu);
		setJMenuBar(menubar);
	}
	
	public void closeApplication()
	{
		System.exit(0);		
	}
	
	public static void main(String ps[])
	{
		new AlienManager().show();
	}
}
(Review ID: 94197)
======================================================================




A JPopupMenu still appears over the component that invoked it
if a menu item from this popup menu launches a PopupDialog 
over the popup menu.
This only occurs if the PopupDiloag is closed without being
moved or resized.

I have only seen this problem on NT.  It did not
occur on Solaris.

Compile and run the program shown below
 - Mo
ve the Frame to the upper left corner of the screen
 - right click the mouse over the Test label.
 - Press any one of the Test menu items that appear.
 - Note that a JDialog appears that covers the
   entire frame.
 - without moving this Dialog, press the close button
 - Note that now on the main frame, the 
    Popup Menu still shows up, even though it isn't really
    there.

This Test label is just not getting redrawn, so it
still shows as if the popup menu was there.


import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.border.EmptyBorder;
 
public class BadDialog1 extends JPanel implements ActionListener
{
    static JFrame frame;
    JPopupMenu popupMenu;
    JButton quitButton = null;
    JButton closeButton = null;
    JDialog badDialog = null;

    public BadDialog1()
    {
        setLayout(new BorderLayout());
        JLabel testLabel = new JLabel("Test");
        testLabel.addMouseListener(new MouseAdapter()
        {
            public void mousePressed(MouseEvent e)
            {
                if(e.isPopupTrigger())
                {
                    popupMenu.show((Component)e.getSource(), e.getX(), e.getY());
                }
            }
            public void mouseReleased(MouseEvent e)
            {
                if(e.isPopupTrigger())
                {
                    popupMenu.show((Component)e.getSource(), e.getX(), e.getY());
                }
            }
        });
        setBorder(new EmptyBorder(10, 10, 10, 10));
        createBadDialog();
        quitButton = new JButton("Quit");
        quitButton.addActionListener(this);
        add("Center", testLabel);
        add("South", quitButton);
        popupMenu = new JPopupMenu();
        JMenuItem item1 = new JMenuItem("Test1");
        item1.addActionListener(this);
        JMenuItem item2 = new JMenuItem("Test2");
        item2.addActionListener(this);
        JMenuItem item3 = new JMenuItem("Test3");
        item3.addActionListener(this);
        JMenuItem item4 = new JMenuItem("Test4");
        item4.addActionListener(this);
        popupMenu.add(item1);
        popupMenu.add(item2);
        popupMenu.add(item3);
        popupMenu.add(item4);
    }

    public static void main(String[] args)
    {
        int INITIAL_WIDTH = 300;
        int INITIAL_HEIGHT = 250;
        frame = new JFrame("BadDialog");
 
        BadDialog1 test = new BadDialog1();
 
        frame.addWindowListener(new WindowAdapter()
        {
            public void windowClosing(WindowEvent e)
            {
                System.exit(0);
                  frame.setVisible(true);
            }
            public void windowClosed(WindowEvent e)
            {
              System.out.println("In windowClosed");
            }
        });
        frame.getContentPane().add("Center", test);
        frame.pack();
        frame.setSize(INITIAL_WIDTH, INITIAL_HEIGHT);
        Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
        frame.setLocation(screenSize.width/2 - INITIAL_WIDTH/2,
           screenSize.height/2 - INITIAL_HEIGHT/2);
        frame.setVisible(true);
    }

    private void createBadDialog()
    {
        badDialog = new JDialog();
        badDialog.getContentPane().setLayout(new BorderLayout());
        JPanel centerPanel = new JPanel(new GridLayout(1, 1));
        centerPanel.setPreferredSize(new Dimension (800, 500));
        badDialog.getContentPane().add("Center", centerPanel);
        closeButton = new JButton("Close");
        closeButton.addActionListener(this);
        badDialog.getContentPane().add("South", closeButton);
        badDialog.pack();
    }

    public void actionPerformed(ActionEvent event)
    {
        Object source = event.getSource();
        if(source == quitButton)
            System.exit(0);
        else if(source == closeButton)
            badDialog.setVisible(false);
        else
            badDialog.setVisible(true);
    }
}
(Review ID: 94270)
======================================================================




Since I got reply of "not able to reproduce" twice from you, this time I will attach a example which is modified from a sample program in java tutorial. The attached code is for two different file, one is called PopupMenuDemo, another called TestDialog. Please run it and try to reproduce the bug. The bug occurs when the dialog cover PART of the popup menu and then is closed without moving.

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

/*
 * This class adds popup menus to MenuDemo.
 */
public class PopupMenuDemo extends JFrame
                           implements ActionListener {
    JTextArea output;
    JScrollPane scrollPane;
    JPopupMenu popup;

    public PopupMenuDemo() {
        JMenuBar menuBar;
        JMenu menu, submenu;
        JMenuItem menuItem;
        JRadioButtonMenuItem rbMenuItem;
        JCheckBoxMenuItem cbMenuItem;

        addWindowListener(new WindowAdapter() {
            public void windowClosing(WindowEvent e) {
                System.exit(0);
            }
        });

        //Add regular components to the window, using the default BorderLayout.
        Container contentPane = getContentPane();
        output = new JTextArea(5, 30);
        output.setEditable(false);
        scrollPane = new JScrollPane(output);
        contentPane.add(scrollPane, BorderLayout.CENTER);

        //Create the menu bar.
        menuBar = new JMenuBar();
        setJMenuBar(menuBar);

        //Build the first menu.
        menu = new JMenu("A Menu");
        menu.setMnemonic(KeyEvent.VK_A);
        menuBar.add(menu);

        //Build second menu in the menu bar.
        menu = new JMenu("Another Menu");
        menu.setMnemonic(KeyEvent.VK_N);
        menu.getAccessibleContext().setAccessibleDescription(
                "This menu does nothing");
        menuBar.add(menu);

        //Create the popup menu.
        popup = new JPopupMenu();
        menuItem = new JMenuItem("A popup menu item");
        menuItem.addActionListener(this);
        popup.add(menuItem);
        menuItem = new JMenuItem("Another popup menu item");
        menuItem.addActionListener(this);
        popup.add(menuItem);

        //Add listener to components that can bring up popup menus.
        MouseListener popupListener = new PopupListener();
        output.addMouseListener(popupListener);
        scrollPane.addMouseListener(popupListener);
        menuBar.addMouseListener(popupListener);
    }

    public void actionPerformed(ActionEvent e) {
      TestDialog dlg = new TestDialog();
      int x = this.getLocation().x + 50;
      int y = this.getLocation().y + 50;
      dlg.setLocation( x, y );
      dlg.setVisible(true);
    }

    public static void main(String[] args) {
    try{
    UIManager.setLookAndFeel( UIManager.getSystemLookAndFeelClassName() );
    }
    catch( Exception e )
    {
    }
        PopupMenuDemo window = new PopupMenuDemo();

        window.setTitle("PopupMenuDemo");
        window.setSize(450, 260);
        window.setVisible(true);
    }

    class PopupListener extends MouseAdapter {
        public void mousePressed(MouseEvent e) {
            maybeShowPopup(e);
        }

        public void mouseReleased(MouseEvent e) {
            maybeShowPopup(e);
        }

        private void maybeShowPopup(MouseEvent e) {
            if (e.isPopupTrigger()) {
                popup.show(e.getComponent(),
                           e.getX(), e.getY());
            }
        }
    }
}

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

public class TestDialog extends JDialog implements ActionListener
{
  JPanel panel1 = new JPanel();
  BorderLayout borderLayout1 = new BorderLayout();

  public TestDialog(Frame frame, String title, boolean modal)
  {
    super(frame, title, modal);
    try
    {
      jbInit();
      pack();
    }
    catch(Exception ex)
    {
      ex.printStackTrace();
    }
    setSize( 300, 200 );
  }

  public TestDialog()
  {
    this(null, "", false);
  }

  void jbInit() throws Exception
  {
    panel1.setLayout(borderLayout1);
    getContentPane().add(panel1);
    JButton close = new JButton("Close me!");
    panel1.add( close, BorderLayout.CENTER );
    close.addActionListener(this);
  }

  public void actionPerformed( ActionEvent e )
  {
    setVisible(false);
  }
}
(Review ID: 94799)
======================================================================




Show up a frame that has DO_NOTHING_ON_CLOSE as the defaultCloseOperation, click on a menu and when the menu is still showing up, click on the X button on the right-top corner to close the window. In the windowClosing () method, call the setVisible (false) method to hide the window. Call setVisible (true) again to show the same frame, you can see that the menu is still open.

Run the following program to understand the problem:
    - javac Menu.java
    - java Menu
    - Click on "Open" button.
    - Click on the "File" menu.
    - Click on the "X" button when the menu is still seen.
    - Click on the "Open" button again.

----Menu.java----
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.event.*;
import javax.swing.border.*;

public class Menu extends JFrame
{
    JFrame otherFrame;

    public Menu (String title)
    {
        super (title);
        JButton but = new JButton ("Open");
        but.addActionListener (new ActionListener ()
            {
                public void actionPerformed (ActionEvent e)
                {
                    if (otherFrame == null) {
                        otherFrame = new OtherFrame ();
                    }
                    otherFrame.show ();
                }
            });
        getContentPane ().add (but);
    }

    public static void main (String[] args)
    {
        Menu app = new Menu ("Menu");
        app.pack ();
        app.show ();
    }

    static class OtherFrame extends JFrame
    {
        OtherFrame ()
        {
            JMenuBar jmb = new JMenuBar ();
            JMenu jm = new JMenu ("File");
            jm.add (new JMenuItem ("Open"));
            jm.add (new JMenuItem ("Save"));
            jmb.add (jm);
            setJMenuBar (jmb);
            setDefaultCloseOperation (DO_NOTHING_ON_CLOSE);
            addWindowListener (new WindowAdapter ()
                {
                    public void windowClosing (WindowEvent ev)
                    {
                        setVisible (false);
                    }
                });
            setSize (200, 100);
        }
    }
}
----Menu.java----

This happens even if you set Windows LnF. Also the menus are not hidden when the window is moved. On windows, the default behavior is to hide them when the window is moved/deactivated/deiconified.
(Review ID: 96387)
======================================================================




java version "1.2.1"
classic vm (build JDK-1.2.1-A, native threads)

- i have an application with a frame (JFrame) that has a menu bar
- if i open a menu (in my java application) and then i click another
application (my application loses focus) the menu is still shown. it is not
destroyed or the frame doesn't repaint
- i think it is the last one because one of my menus opens a JFileChooser that
apears over the menu (the frame is a small one). if i close the this window
(the file chooser) the menu is still shown. but if i move the file chooser the
frame (probably) repaints corectly so the menu id gone.
(Review ID: 97653)
======================================================================




jdk 1.1.8, swing-1.1.1fcs
/*
    Start with java Slow
    Press mouse button, release mouse button, select item 1, 2, 1, 2 and so on.
    You should see, that the subMenu of 1 does not pop up immediately, but with
some delay. Thats ok.
    Now press mouse button but do no release it, then drag to item 1, 2, 1, 2
and so on.
    You should observe, that the subMenu shows up immediately. Sounds to be ok,
but it is different to
    the above behaviour.
    I claim, that in the second case, the subMenu is painted twice! Immediately
and after the usual delay.
    This results in a performance problem with popups. (on slow computers
selecting in dragging mode
    is so awefully slowly, that it almost killed a java project).
    The fix to bug 4188027 causes the problem.
*/

import javax.swing.*;
import java.awt.event.*;

public class Slow extends JFrame
{
    
    public static final void main ( String[] args ) {
       
       final JFrame f = new JFrame();
       f.setSize(500,500);
       final JPopupMenu popupMenu = new JPopupMenu();

       JMenu menu = new JMenu("   1   ");
       popupMenu.add(menu);
       popupMenu.add(new JMenuItem("   2   "));

       menu.add(new JMenuItem("subMenu"));

       f.getContentPane().addMouseListener(new MouseAdapter() {
           public void mousePressed(MouseEvent e) {
	       popupMenu.show(f.getContentPane(),100,100);
	   }
       });
       
       f.setVisible(true);
    }
}
(Review ID: 97647)
======================================================================
Posted Date : 2005-07-22 03:26:19.0

One workaround:

Calling repaint on the application's JFrame and it's contentPane
after the dialog is dismissed causes the app's main window to get
repainted properly.


A simpler (more localized) workaround:

 Invoke the dialog with a Timer, with a very short delay (20 MS):

    public void showDialogWithOffset ( int xoffset, int yoffset )
        {
		final TestDialog window = new TestDialog(this);
		Dimension size = getSize();
		Point location = getLocation();
		// make dialog a little bigger than the JFrame
		window.setSize ( size.width + 30, size.height + 30 );
		location.translate ( xoffset, yoffset );
		window.setLocation ( location );
		Timer t = new Timer(20, new ActionListener() {
		    public void actionPerformed(ActionEvent ae) {
		        window.show();
		    }
		});
		t.setRepeats(false);
		t.start();
        }





none (remove bug fix 4188027)
(Review ID: 97647)
======================================================================

The timer workaround described above works well.  It essentially gives
the menu time to pop down before the dialog pops up, ensuring that the
underlying saveunder bits are cleared of the popup.

  xxxxx@xxxxx   1999-12-20

This sounds like general paintology problems, but I'll look at it to confirm this.
  xxxxx@xxxxx   1998-11-18

This happens consistently on Windows; I can't get it to happen on Solaris.
I believe it is a repaint problem in Windows AWT.
  xxxxx@xxxxx   1999-10-11

Workaround added
  xxxxx@xxxxx   1999-10-19

The win32 AWT is definitely NOT generating the expected paint event
that would trigger the underlying JFrame to update properly.  It looks
as if it's using its own backing store to repaint the damaged area,
and the problem of course is that the popup menu is no longer up and
so the underlying region requires a live update.

Note that on Solaris the expected paint event is properly delivered
and so the JFrame repaints properly.

  xxxxx@xxxxx   1999-11-29

I've just confirmed with the AWT team that win32 does turn on 
save-under for dialogs and windows (not for frames), so this is
likely the culprit.  The oddity is that it's supposed to detect
that an update occurred to the underlying window and essentially
throw out the save-under bits.  There may be a timing issue here.

Reassigning to the AWT.

  xxxxx@xxxxx   1999-11-29

We need to verify that the backing store is at least partly responsibile
by removing the line

    lpwc->style     |= CS_SAVEBITS; // improve pull-down menu performance

from AwtWindow::FillClassInfo in awt_Window.cpp.
  xxxxx@xxxxx   1999-12-02

I've confirmed that turning off saveunder in the native Windows AWT
code indeed clears up the bug (unfortunately it also makes repainting
areas under menus slower!).

  xxxxx@xxxxx   1999-12-20

We need to fix this in Merlin.  
  xxxxx@xxxxx   2000-04-28


In going back to investigate a workaround I discovered that I am unable to
reproduce this problem with Windows2000. (perhaps there was a MS bug in
save-under, which was fixed in W2000?)

Anyhow, I can still reproduce it with Windows98.

  xxxxx@xxxxx   2000-06-21


Due to developer demand, committing to Ladybird as well.  
  xxxxx@xxxxx   2000-06-21

I am upping the priority of this one as I have just closed at a number of bugs as duplicates of this (this behavior has existed for quite a while now).
  xxxxx@xxxxx   2000-09-15

Below is some more detail from the responsible engineer:   xxxxx@xxxxx   

after investigateing this problem i think that we have
race condition.  The problem is as follows:
after mouse click on menu item Swing calls method 
javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1029)
in this method we call javax.swing.MenuSelectionManager.clearSelectedPath
and javax.swing.AbstractButton.doClick consistently, and first of them 
causes call of setVisible after that we initialize repainting work, and 
the second causes call of actionPerformed in which we show a dialog.  
But painting and dialog showing are asynchronous and we have race between 
them.  And, as result of this race, we don't receive WM_PAINT after closing 
the dialog, because Windows think that nothing changed under it.

In Ladybird we have the same problem with the same two calls but in 
other place, because this code was changed in Merlin.

So, i found only one way to fix this problem in awt - remove one line 
from awt_Window.cpp:
lpwc->style     |= CS_SAVEBITS; // improve pull-down menu performance

Or we can sugget to Swing handle this problem by using timer for second 
call (as in workaround).

  xxxxx@xxxxx   2000-11-21

I had this problem running SwingSet using JDK1.2 RC2.

I also believe that this bug didn't exist
in Swing 1.0.3.

I have this problem too.
Every time I select a menu item that causes a
JDialog to pop up which is a) wider than its
parent frame and b) covering a part of the menu
the menu item belongs to, the background of
the frame is not repainted properly when
the dialogue is closed. This should really
be fixed BEFORE the final JDK1.2 release!

The same thing happens with the JFileChooser, So any
Open or Save MenuItems cause this to happen.
A repaint() of the JFrame including the JMenu
is a work around. The problem occurs on the
1.2 version on Windows. On Unix (HP) using the
JFC 1.1 and the JDK 1.1 this doesn't happen.

I have tested it. And maybe foud a workaroud:
paintImmediately(x,x,x,x);
I replaced _jPopupMenu.setVisible(false);
with paintImmediately(0,0,getWidth(),getHeigth());
and i didn't get the wrong paint window anymore

I have this or very similar problem on Win 98 platform. It was not present
using JDK 1.2beta4, but the much awaited JDK 1.2 has really messed up the
display, using standard 'metal' or native Windows L&F.
It appears to be the *cursor* rectangle which is not always repainted when
moved.
Particularly evident in JMenu's and JFileChooser's.

This bug is new in swing1.1, and really should
have been fixed before releasing 1.2. Now I
have to choose between going back to 1.1.7B,
or waiting for the bug to be fixed before
I can ship my own software... :-(

This bug is new in swing1.1, and really should
have been fixed before releasing 1.2. Now I
have to choose between going back to 1.1.7B,
or waiting for the bug to be fixed before
I can ship my own software... :-(

O get the same problem when running under windows.  This bug greatly reduces
the professional look of my applications.  I hope it's fixed soon.

Here's my workaround based on the idea of joco.
It repaint the JPanel in which the invoker is
embedded, since just repainting the component
itself is not enough (the menu might fall
partly outside of the component). Please note
that my workaround fails if:
- the component is not placed in a JPanel, or
- part of the menu is outside of the JPanel,
but under the JDialogBox that was brought up
by the menu selection.

import java.awt.*;
import javax.swing.*;

public class mjnJPopupMenu extends JPopupMenu
{

	public mjnJPopupMenu()
	{
		super();
	}

public mjnJPopupMenu(String label)
{	super(label);
}
public void setVisible(boolean flag)
//
// repaints the first JPanel it finds
//
{	super.setVisible(flag);
	if (!flag)
	{	Component c = getInvoker();
		for (;;)
		{	if (c instanceof JPanel)
				break;
			c = c.getParent();
			if (c == null)
				break;
		}
		if (c instanceof JComponent)
		{	JComponent jc = (JComponent)c;
			jc.paintImmediately(0, 0, jc.getWidth(), jc.getHeight());
		}
	}
}
}

Here's my workaround based on the idea of joco.
It repaint the JPanel in which the invoker is
embedded, since just repainting the component
itself is not enough (the menu might fall
partly outside of the component). Please note
that my workaround fails if:
- the component is not placed in a JPanel, or
- part of the menu is outside of the JPanel,
but under the JDialogBox that was brought up
by the menu selection.
import java.awt.*;
import javax.swing.*;
public class mjnJPopupMenu extends JPopupMenu
{
public mjnJPopupMenu()
{	super();
}
public mjnJPopupMenu(String label)
{	super(label);
}
public void setVisible(boolean flag)
//
// repaints the first JPanel it finds
//
{	super.setVisible(flag);
	if (!flag)
	{	Component c = getInvoker();
		for (;;)
		{	if (c instanceof JPanel)
				break;
			c = c.getParent();
			if (c == null)
				break;
		}
		if (c instanceof JComponent)
		{	JComponent jc = (JComponent)c;
			jc.paintImmediately(0, 0, jc.getWidth(), jc.getHeight());
		}
	}
}
}

Here is a workaround for custom JDialog extensions.
Call this private method after closing the dialog:
private void cleanupPopup()
	{
	// Necessary to remove popup menu (Java bug# 4189244)
	getOwner().invalidate();
	getOwner().repaint();
	}
You can probably use this same trick if you create
manual JOptionPane's rather than the built-in
convenience popups (showXxxxDialog).  See the 
JOptionPane API documentation for a decent 
explaination on manually creating dialogs with 
JOptionPane.  In this case you'll have to call
the following after the dialog returns:
dialog.getOwner().invalidate();
dialog.getOwner().repaint();

No need to confirm it, just fix it

I'm having the same problem, but with our own Dialogs
which are subclassed from JDialog.  This happens
in JDK1.2.2 browser plug-in.

Workaround: invoking commands from popup-menus delayed
(by using SwingUtilities.invokeLater) solved this problem in my app.

Okay, xxxxx@xxxxx, now you've been looking
at the problem since November, 1998.
I'd say it's time for a coffee break!

I think I've encountered this bug on 1.2.2 as well 
and I've noticed on Win32 (via Spy++) that the JFileChooser dialog window is
created with the CS_SAVEBITS option which will save the image
of the bits that are about to be obscured by a window and restore
them when the window is disposed. Could this be the why this is happening?
My workaround was to issue a repaint on the control(s) within the parent
window. Not pretty.
I posted this for bug 4246176 since it looks similar.

The following code works good for me...
class PopupMenuWorkaround extends JPopupMenu
{
  public void setVisible(boolean visible)
  {
    super.setVisible(visible);
    if (!visible)
    {
      Component invoker = getInvoker();
      invoker.repaint();
    }
  }
}

Hello,
I think I've the same problem in following program.
The menu don't display correctly with wrong highlights and sometimes partially
disapearance of
a menu text.
I run on an Pentium 133 32mb / Windows 98 with
the jdk 1.2.2
(Since it's my first attemp to make a java application I could have make a
mistake.)

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
public class Editor extends JPanel
{
  static JFrame frmEditor;
  public static void main (String _args[])
  {
    frmEditor = new JFrame("Editor v1.0");
    Editor objEditor = new Editor();
    frmEditor.getContentPane().add("Center", objEditor);
    frmEditor.addWindowListener
    (
      new WindowListener()
      {
        public void windowActivated(WindowEvent _event)
        {
        }
        public void windowClosed(WindowEvent _event)
        {
        }
        public void windowClosing(WindowEvent _event)
        {
          System.exit(0);
        }
        public void windowDeactivated(WindowEvent _event)
        {
        }
        public void windowDeiconified(WindowEvent _event)
        {
        }
        public void windowIconified(WindowEvent _event)
        {
        }
        public void windowOpened(WindowEvent _event)
        {
        }
      }
    );
    frmEditor.setSize(300, 300);
    frmEditor.setVisible(true);
  }
  Editor()
  {
    super(new BorderLayout(), true);
    add(createMenu(), "North");
  }
  public JMenuBar createMenu()
  {
    JMenuBar  menuBar = new JMenuBar();
    JMenu     menu;
    JMenuItem menuItem;
    menu = (JMenu) menuBar.add(new JMenu("Bestand"));
    menu.setMnemonic('B');
    menuItem = (JMenuItem) menu.add(new JMenuItem("Afsluiten"));
    menu.setMnemonic('A');
    return menuBar;
  }
}

The workaround above doesn't work for dialogs brought up by JMenus, because
they have
an internal popup menu, which we can't override. So I subclassed JMenu, and
overrode 
a different method:

  public void setPopupMenuVisible(boolean vis)
  {
    super.setPopupMenuVisible(vis);
    if (!vis)
    {
      Component c = getPopupMenu().getInvoker();
      if (c instanceof JComponent)
      {
        Container parent = (Container) c;
        while ((parent instanceof JComponent))
        {
          c = parent;
          parent = c.getParent();
        }
        JComponent jc = (JComponent)c;
        jc.paintImmediately(0, 0, jc.getWidth(), jc.getHeight());
      }
    }
  }

The code is essentially identical.

This bug occurs in jdk1.3 rc1 on Windows NT too.
Run the demo "Notepad" and move the mainwindow
for about 200 pixels to the right. Choose the
menu "Debug->Show Elements" and close the dialog
"Element" after it becomse visible. The Menu
does not disappear completely.

Looks as if this bug is here to stay. 
SwingUtilities.invokeLater solves the problem in every 
version I tried, including JDK1.3RC1.

I have experienced this bug too. On my machine, I was able 
to fix it (from the user side) by changing the screen 
resolution and the putting it back to its original setting. 
After that, the programs (Forte, specifically) seemed to 
work correctly.

Bug id 4265726 is a non-reported duplicate of this one.

There is a really simple and, more importantly,
highly localized workaround for this problem.
You just need to attach a WindowAdapter to the
window which does not get repainted appropriately,
and have it repaint the window when it is activated:

public void windowActivated (WindowEvent ev)
{
    ev.getWindow().repaint();
}

This Adapter can be used as a singleton since it is
stateless. In most cases it only needs to be
attached to the application's main window.

Practical observation in our application shows that
it is seldom activated without exposing the bug
discussed here. Swing shortcuts the repaint with the
double buffer and you probably won't even notice it.

kre's workaround works, however, the AWT/Swing
(re)paint system is so slow that you can still
see the menu before the frame is repainted.

This area is buggy in NT as well. I ocasionally noticed 
this kind of thing happening when I was working in JBuilder 
(with my manager looking over my shoulder - always the 
way). A pity, because JBuilder is one of the more serious 
apps out there using Java.

I do the repaint on windowDeactivated. It works too and you 
don't see the menu for a short time when it gets activated.

I am facing the same problem on WINNT in JDK1.3 also. 

For a bug as significant as this, almost two years and running with no fix in Sun's software is extremely 
frustrating and hard to accept. This issue should be near the top of the list of things to fix. The fact that 
Java lacks reliable user interface components on Windows 98/95/NT using SWING makes the language and 
platform much less desirable for development. A sentiment I've heard from a number of developers.

This bug should really be fixed, I downloaded the 30MB SDK 
1.3 thinking it would make it disappear but it didn't, and 
so I, a beginner programmer had to read the whole page and 
try different suggested solutions, in the end I discovered 
all you have to do is make sure the new dialog doesn't 
completely cover the menuItem, this was acheived easily 
with:

PointLocation = getLocation();
location.translate(100, 100); //moving new dialog 100 down, 
100 left, worked for me

newDialogName.setLocation(location);

if this code is put in the calling class, and you adjust it 
so that the new dialog doesn't cover the JMenuItem, the 
problem seems to go away.

Put a black 'X' against Sun and xxxxx@xxxxx and move on!

Yeah, two years later and nothing, no fix. I have JDK 1.3 
and I can still reproduce this. I think Sun's JDK 
developers are so dumb they don't know how to fix it. 
Unbelievable.

I worked around this by adding a menu listener to each menu:

MenuListener repaintFix = new MenuListener() {
    public void menuSelected(MenuEvent evt) {
        MainScreen.this.invalidate();
    }
    public void menuCanceled(MenuEvent evt) {}
    public void menuDeselected(MenuEvent evt) {}
};

which forces the frame to repaint when the dialog closes.
This may have the same problem as kre's workaround for some
people (that you can still see the menu after the dialog
closes and before it repaints) but I haven't had a problem
with it.

I don't have any popup menus that open dialogs, but
something similar would probably work for them too.

Another alternative to the Timer thread is to use 
SwingUtilities.invokeLater(). This posts the work to the 
swing event queue and won't get executed until after the 
current swing event has been handled, guaranteeing that the 
menu clean-up will have a chance to run before the dialog 
shows. Can be done by overriding show:
public void show() {
    SwingUtilities.invokeLater( new Runnable() {
        public void run() {
            super.show();
            }
       });
    }

Hey, what's going on here ??!!??!!
A top-voted bug is not fixed since 2 years !?!?
Still valid in JDK 1.3

Finally, Sun seems to be WORKING on that 2-year-old serious bug.
I hope they can FIX it in less than 2 years!

I note that this bug has a closed status - I have the bug 
in the 1.3 release. I assumed since it is closed there is a 
fix but I don't see what it is. Is there a 1.3 patch or 
upgrade or has it been closed with a work-around? Since we 
were trying to use Java to develop an application this is 
quite a serious bug to us, I do not really want to clutter 
our code with work-aroounds.

Please let me know if there is a fix reather than these 
workarounds available. 

the workaround I used was to add the following code to my base dialog class constructor
	addComponentListener (new ComponentAdapter ()
	{
	  public void componentResized (ComponentEvent e)
	  {

	    e.getComponent ().removeComponentListener (this);	// done
	
	    setLocation (getLocation ());	
	  }				
	});

this will cause the popup menu to disappear

To kre & PoliM, thank you.  A clean, elegant workaround!

The workaround posted in the "workaround" session works but be aware that it does NOT work for Modal 
Dialog! Take a look at the code and you'll see why. The Timer (or invokeLater) will NOT execute the show() 
in the same event. Thus if you're using code in this way:

modalDialog.setVisible(true);
if(modalDialog.okClicked()) {
    // ...
}

Guess what, the setVisible won't block anymore and it will go straight to the "if" part. Just be aware of that 
if you're trying to use this workaround.

Here is my workaround (thanks to marcelnijman & Vidmich)
It solve the problem for overlaping JDialog & JOptionPane

java version "1.3.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 
1.3.0_01)
Java HotSpot(TM) Client VM (build 1.3.0_01, mixed mode)

// override setVisible of JPopupMenu
public void setVisible(boolean flag) {
  if (flag) {
    super.setVisible(flag);

  } else {
    Point p = getLocationOnScreen();
    JComponent invoker = (JComponent) getInvoker();
    SwingUtilities.convertPointFromScreen(p, invoker);

    super.setVisible(flag);

    // Repaint only the old popup area.
    invoker.paintImmediately(p.x, p.y, getWidth(), getHeight
());
  }
}

This bug by no means is fixed.  I STILL find the problem 
in 1.4.  I can't get any of the workarounds to work either.

how to check the condition for enabled and disabled popup menu item in java swing

how to apply the condition on popup menu for enable and disable popup menu item for different different folders and file