Skip to main content

Need feedback from Sun

27 replies [Last post]
cowwoc
Offline
Joined: 2003-08-24

Hi,

I am utter frustrated with Swing ;)

I've been trying to rework JPopupMenu to support poping up a menu over the taskbar (for the system tray) and like most of the other Swing classes, it is a total mess. It is practically impossible to do anything with JPopupMenu.

The only thing I wanted to do was modify the field "popupPostionFixDisabled" from a per-class setting to a per-object setting. The only way I found to do that is copy/paste the contents of JPopupMenu into a new file, modify it to my liking, then stick it onto the bootclasspath.

The problem then is that one cannot modify the bootclasspath under Java Webstart, which my application absolutely requires, so all of this work is for nothing.

Surely there has to be a better way to do all this. Can someone from Sun please help me with this? To get a background of what I'm trying to do, read here: http://www.javadesktop.org/forums/thread.jspa?threadID=6309&tstart=0

I've gotten everything to work except this:

1) If I use a JPopupMenu with no invoker: I make the JPopupMenu visible, but then keyboard navigation does not work. The owner window has isFocusableWindow() set to false and invoking setFocusableWindow(true) does not change anything. Without this window being focusable, keyboard navigation does not work and I absolutely need it to work.

2) If I use a JPopupMenu with an invoker: I make the invoker visible, then the JPopupMenu visible, then call toFront() on the invoker to give it focus. Now keyboard navigation works -- toFront() was required to make this possible. The problem is that now I would like to reposition the invoker such that it covers the taskbar. As you recall, it is impossible to make set JPopupMenu's location such that it covers the taskbar; the "popupPostionFixDisabled" property makes this impossible. So what I do is display the JPopupMenu, then move the underlying window that is containing it. This works fine *except* the JPopupMenu closes itself, as if someone clicked on it or something. So I'm stumped.

I believe that if I could just display the JPopupMenu in the correct position to begin with (by modifying popupPostionFixDisabled to true) then I could get everything working. However, I don't want to modify this property globally because other JPopupMenus are not taskbar popups and I may not modify their behavior. Even if I was willing to change this behavior globally (which, again, is far from ideal) setting this property using "-Djavax.swing.adjustPopupLocationToFit=false" is not an option because, as mentioned before, Java Webstart won't allow one to set JVM command-line options for my application.

From my point of view what I need is:

1a) The ability to modify "popupPostionFixDisabled" on a per-object basis; or,
1b) The ability for JNLP files to specify JVM arguments
2) A solution as soon as possible, not having to wait until Mustang.

I think the best course of action is "1a". Specifically, please make this property a per-object field, and add a setter/getter for it. I know normally this would be construed as a RFE (hence having to wait for Mustang) but I feel that in this case we can make an exception because no real functionality is changing: you are simply exposing getter/setter methods for a preexisting field. There is almost no chance of this breaking anything.

I would like to close by adding that I plan on contributing my library to JDIC in the hopes that others will benefit from it. I hope Sun will show its commitement to supporting grass-root projects such as this.

I look forward to your feedback,
Gili

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
zander
Offline
Joined: 2003-06-13

> It sounds like the WindowListener (specifically
> windowDeactivated) that may be
> causing you guys problems here.

my related problem makes me think thats not the case;
I have a mediumWeight popup on a JMenuPopup and clicking up that first popup makes both dissapear on 1.5, where it did not on 1.4.*

A mediumWeightPopup is a widget that is displayed in the layeredPane of its parent window.

If I failed to make myself clear; start http://uic.sourceforge.net/demo/demo-secure.jnlp and open the date-edit (combobox-type) on the data-chooser page. Next click on the 'months' button and notice a popup coming up. Clickingon that popup should not close the date-edit.

kleopatra
Offline
Joined: 2003-06-11

Just a short observation:

> Setting
> "popupPostionFixDisabled" fixes the problem (since I
> can just position myself over the taskbar in the
> first place)

seems like the setting is respected on showing the popup (allowing overlap). But when (while the popup is visible) I hide the taskbar and make it visible again, the popup is pushed to a position not overlapping the taskbar.

Jeanette

cowwoc
Offline
Joined: 2003-08-24

That's normal win32 because the taskbar has "always on top" set and if your popup has it the same, the most it guarantees is that you stay on top until someone clicks on the taskbar. That's fine because popups get dismissed when they lose focus anyway.

Gili

zander
Offline
Joined: 2003-06-13

> b) the toFront on the invoker takes the focus (and
> thus let the popup disappear - is that 1.5 specific,
> Thomas?, did not try, it's too late for me :)

That indeed seems to be new in 1.5
I spent close to 3 hours today finding out why my Popup gets closed in a similar situation but failed to find why the popup is closed. It seems to be a native (or AWT) thing since I did not find any listeners on any component of the AWT hierarchy that explains it.

Scott: Do you know how a JPopupMenu is closed by Java (since 1.5) ?

Scott Violet

On Mon, Nov 08, 2004 at 01:20:43PM -0500, swing-feedback@javadesktop.org wrote:
> > b) the toFront on the invoker takes the focus (and
> > thus let the popup disappear - is that 1.5 specific,
> > Thomas?, did not try, it's too late for me :)
>
> That indeed seems to be new in 1.5
> I spent close to 3 hours today finding out why my Popup gets closed
> in a similar situation but failed to find why the popup is closed.
> It seems to be a native (or AWT) thing since I did not find any
> listeners on any component of the AWT hierarchy that explains it.
>
> Scott: Do you know how a JPopupMenu is closed by Java (since 1.5) ?

I'd have to dig through the code to be entirely confident here. On a
quick cursory look BasicPopupMenuUI installs MouseListeners,
AWTEventListeners, ComponentListeners and WindowListeners. It sounds
like the WindowListener (specifically windowDeactivated) that may be
causing you guys problems here. Not positive though as I didn't try
and debug it. I suspect we'll have a bunch of bugs to look through
shortly from Gili and figure out what's going on from there.

-Scott

cowwoc
Offline
Joined: 2003-08-24

Zander brings up a good point. My code will only work under JDK 1.5, not only because toFront() but because so many changes occurs in JPopupMenu between JDK 1.3/1.4 and 1.5.

Personally, I only plan on using my API under 1.5 so this does not concern me, but I suspect a lot of the users of the API will be asking for JDK 1.3/1.4 support. I'd appreciate your help in investigating what changes occured so I can fold them back into my API.

(Or maybe it makes sense for us to only support JDK 1.5 in order to conserve resources?)

Just food for thought.

Gili

kleopatra
Offline
Joined: 2003-06-11

Gili,

>
> I tested the behavior you mentioned without any
> native manipulation and the popup still went away. I
> am pretty sure you are using JDK 1.4 and I am using
> JDK 1.5 which would explain the different behavior.

I'm pretty confident that I have total control about the jdk I'm using

So my guess about the native part was wrong - but your statement about doing "exactly" the same as well (apart from the native vs. normal section):

you use:

> activeMenu.setVisible(true);

whereas I do (see my code snippet)

[code]
popup.show(invoker, screen.x, screen.y)
[/code]

Don't know if that's the difference, but we should compare running code from now on - you start (because it's your problem :-)

Jeanette

cowwoc
Offline
Joined: 2003-08-24

Jeanette,

I tried this code (per your suggestion) and I still get the same result:

menuRoot.setSize(preferredSize.width, preferredSize.height);
menuRoot.setVisible(true);
Point newPosition = menuRoot.getLocation();
activeMenu.show(menuRoot, 0, 0);
menuRoot.setLocation(0, 0);

The killer seems to be the last line where I move the invoker far away from its original position after the popup menu has been made visible.

kleopatra
Offline
Joined: 2003-06-11

> Jeanette,
>
> I tried this code (per your suggestion) and I
> d I still get the same result:
>
> menuRoot.setSize(preferredSize.width,
> width, preferredSize.height);
> menuRoot.setVisible(true);
> Point newPosition = menuRoot.getLocation();
> activeMenu.show(menuRoot, 0, 0);
> menuRoot.setLocation(0, 0);
>
> The killer seems to be the last line where I move
> ove the invoker far away from its original position
> after the popup menu has been made visible.

No, I don't think so (re-location works with no side-effect at all in my context). Instead, I think the killer is somewhere in the preparing code which you don't show. So please show a small, complete, compilable and runnable example that demonstrates the problem.

Jeanette

cowwoc
Offline
Joined: 2003-08-24

Here is a testcase:
[code]
package com.tog.tray.example;

import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.JFrame;
import javax.swing.JMenuItem;
import javax.swing.JPopupMenu;
import javax.swing.UIManager;

public class Testcase
{
public static void main(String[] args)
{
try
{
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
JPopupMenu popupMenu = new JPopupMenu();
JMenuItem menuItem = new JMenuItem("choice 1");
ActionListener actionListener = new ActionListener()
{
public void actionPerformed(ActionEvent e)
{
JMenuItem menuItem = (JMenuItem) e.getSource();
System.out.println(menuItem.getText());
}
};
menuItem.addActionListener(actionListener);
popupMenu.add(menuItem);
menuItem = new JMenuItem("choice 2");
menuItem.addActionListener(actionListener);
popupMenu.add(menuItem);
menuItem = new JMenuItem("choice 3");
menuItem.addActionListener(actionListener);
popupMenu.add(menuItem);

JFrame menuRoot = new JFrame();
menuRoot.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
menuRoot.setUndecorated(true);
menuRoot.setSize(menuItem.getPreferredSize());
menuRoot.setLocation(800, 940);
popupMenu.setInvoker(menuRoot);
menuRoot.setVisible(true);
popupMenu.show(menuRoot, 0, 0);
menuRoot.toFront();

menuRoot.setLocation(0, 0); // Remove this line and everything works fine
}
catch (Exception e)
{
e.printStackTrace();
}
}
}
[/code]

Message was edited by: zander
added code tags.

kleopatra
Offline
Joined: 2003-06-11

After adjusting to my screen size - the popup is shown as a grey rectangle without the menuItems, moving the mouse over it does show the text. That's generally a hint that something's wrong with the realization of the ui.

After playing a bit, I see some problems with your code:

a) you are moving the invoker, not the popup's ancestor window
b) the toFront on the invoker takes the focus (and thus let the popup disappear - is that 1.5 specific, Thomas?, did not try, it's too late for me :)
c) probably a threading problem, the popup.show is done before the frame is ready.

Here is the slighly adjusted code which does show the popup at the changed location:

[code]

import java.awt.Point;
import java.awt.Window;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.*;
import javax.swing.JFrame;
import javax.swing.JMenuItem;
import javax.swing.JPopupMenu;
import javax.swing.UIManager;

public class GiliPopup {

public static void main(String[] args) {
try {
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
final JPopupMenu popupMenu = new JPopupMenu();
JMenuItem menuItem = new JMenuItem("choice 1");
ActionListener actionListener = new ActionListener() {

public void actionPerformed(ActionEvent e) {
JMenuItem menuItem = (JMenuItem) e.getSource();
System.out.println(menuItem.getText());
}
};
menuItem.addActionListener(actionListener);
popupMenu.add(menuItem);
menuItem = new JMenuItem("choice 2");
menuItem.addActionListener(actionListener);
popupMenu.add(menuItem);
menuItem = new JMenuItem("choice 3");
menuItem.addActionListener(actionListener);
popupMenu.add(menuItem);

final JFrame menuRoot = new JFrame("??");
menuRoot.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
menuRoot.setUndecorated(true);
menuRoot.setSize(menuItem.getPreferredSize());
menuRoot.setLocation(800, 700);
menuRoot.setVisible(true);
SwingUtilities.invokeLater(new Runnable() {

public void run() {
popupMenu.show(menuRoot, 0, 0);
// menuRoot.toFront();
Window window = SwingUtilities.windowForComponent(popupMenu);
if (window != null) {
Point windowLocation = new Point(800, 700);
window.setLocation(windowLocation.x, windowLocation.y);
}

}
});
} catch (Exception e) {
e.printStackTrace();
}
}
}

[/code]

Good night
Jeanette

PS: please have a look at the help to learn how to format code here in the forum.

cowwoc
Offline
Joined: 2003-08-24

Jeanette,

Well done. The missing piece of the puzzle was moving the windowForComponent() as opposed to the invoker. Three issues remaining to be solved:

1) Flickering when we popup from position adjacent to taskbar to position covering taskbar. Setting "popupPostionFixDisabled" fixes the problem (since I can just position myself over the taskbar in the first place) but I'm unsure of how this will affect the behavior of normal JPopupMenus for the rest of the system. I think I'd rather play safe on this one . . . Again, ideally Sun should expose an API getter/setter for this property and make it a per-object property. Another possibility that I submitted as an RFE is that if the JPopupMenu has no invoker, popupPostionFixDisabled should be enabled by default. That is, having no invoker is equivilent to the developer saying: "This JPopupMenu is meant to pop out of the desktop".

2) Why does toFront() work but requestWindowFocus() does not?

3) Why can't I get a JPopupMenu with no invoker to get keyboard focus?

Maybe you have an idea on how to solve some of these?

Thanks,
Gili

cowwoc
Offline
Joined: 2003-08-24

Good news. I fixed the flickering problem using some creative use of Reflection and subclassing of JPopupMenu.

Two more problems/questions remain.

cowwoc
Offline
Joined: 2003-08-24

Ok, I cannot get this working with JDialog as the invoker for the same reason I cannot get it without an invoker at all: both use a shared invisible frame and in both cases I cannot get keyboard navigation to work.

Using a JFrame works, but then the JFrame shows up in the taskbar. I can modify this using JNI but not quickly enough and the resulting affect is not pretty. I need to get this working with a JDialog or no-invoker.

Can anyone please try getting the previous testcase to work with a JDialog?

Thanks,
Gili

cowwoc
Offline
Joined: 2003-08-24

Ok, according to http://java.sun.com/docs/books/tutorial/uiswing/misc/focus.html

----- beginning of quote -----
JWindow and focus: If you happen to use a JWindow in your GUI, you should know that the JWindow's owning frame must be visible for any components in the window to get the focus. By default, if you don't specify an owning frame for a JWindow, an invisible owning frame is created for it. The result is that components in JWindows might not be able to get the focus. The solution is to either specify a visible owning frame when creating the JWindow (in the API reference documentation), or to use an undecorated JFrame (in the Creating a GUI with JFC/Swing trail) instead of JWindow.
----- end of quote -----

This is bad news. I guess this explains why a JPopupMenu with no invoker doesn't get keyboard focus properly. Does anyone have any idea how to trick Swing into giving the JPopupMenu focus even though its container is not visible or if it must be visible, how to make the container visible without showing up on the taskbar. The only way I can think up of would involve heavy use of JNI again. Any ideas?

Gili

cowwoc
Offline
Joined: 2003-08-24

Ok, I'm done. I used JNI to make the JFrame visible but not show up in the taskbar. This hack is ugly because one must hide the window, make the style changes, and make it visible again. That's simply how win32 works, otherwise it ignores your style changes.

It seems to work fine under my machine (no flickering) but I wonder if it will flicker under slower (say 500MHz) machines. Does anyone have a slower machine handy to test this on?

kleopatra
Offline
Joined: 2003-06-11

>
> 2) If I use a JPopupMenu with an invoker: I make the
> invoker visible, then the JPopupMenu visible, then
> call toFront() on the invoker to give it focus. Now
> keyboard navigation works -- toFront() was required
> to make this possible. The problem is that now I
> would like to reposition the invoker such that it
> covers the taskbar. As you recall, it is impossible
> to make set JPopupMenu's location such that it covers
> the taskbar; the "popupPostionFixDisabled" property
> makes this impossible. So what I do is display the
> JPopupMenu, then move the underlying window that is
> containing it. This works fine *except* the
> JPopupMenu closes itself, as if someone clicked on it
> or something. So I'm stumped.
>

I can't reproduce the closing (but then I can't make the popup or any other window to show _above_ the tray - only below the tray) - so that maybe related to your native hack.

What I did do to simulate your setup:

a) show the invoker in the position of the popup (in the region of the tray, but below)
b) open the popup "near" its final position
c) move the popup's ancestor window into final position

this still has the problem of a slight flicker, but maybe it's acceptable

Here's the code snippet for showing the popup:

[code]

private void showPopup(Component invoker) {
Point screen = getPopupLocationOnScreen();
SwingUtilities.convertPointFromScreen(screen, invoker);
popup.show(invoker, screen.x, screen.y);
Window window = SwingUtilities.windowForComponent(popup);
if (window != null) {
Point windowLocation = getPopupLocationOnScreen();
window.setLocation(windowLocation.x, windowLocation.y);
}
KeyboardFocusManager.getCurrentKeyboardFocusManager().focusNextComponent(popup);
}

[/code]

the line explicitly requesting the focus is necessary only if the popup contains arbitrary components (to make it accessible to tab without previously clicking on it)

seems to work both on 1.4 and 1.5 (under win2k)

Greetings
Jeanette

cowwoc
Offline
Joined: 2003-08-24

Jeanette,

I am surprised the popup doesn't dismiss itself for you because I am doing exactly what you do. Display the popup, modify it natively so it can cover the taskbar, then setLocation() to move it over the taskbar and it closes itself. Maybe the reason you don't experience the same thing is because your code doesn't actually move the popup anywhere inside the if statement. Correct me if I'm wrong, but isn't it calling setLocation() on the popup's existing location?

The good news is that I (probably) found a workaround, although I am still upset at Sun for making things so difficult. Instead of using the bootclasspath approach I'm going to patch JPopupMenu at runtime. I really have no other choice :(

If this approach works I plan on submitting my library to JDIC and opening a BugParade issue listing everything I needed to do to get this to work so they can modify JPopupMenu to make it possible using pure Java. There is no excuse in the world for someone to have to do the amount of hacking I've been doing over the past couple of weeks. There has to be a better way than this.

Gili

kleopatra
Offline
Joined: 2003-06-11

> Jeanette,
>
> I am surprised the popup doesn't dismiss itself for
> you because I am doing exactly what you do.

No, you aren't doing "exactly" what I do :-)

> Display
> the popup, modify it natively so it can cover the
> taskbar, then setLocation() to move it over the
> taskbar and it closes itself.

the difference is in "natively". So I suspect the difference in behaviour results from this native manipulation (obviously that's an educated guess only :-)

> Maybe the reason you
> don't experience the same thing is because your code
> doesn't actually move the popup anywhere inside the
> if statement. Correct me if I'm wrong, but isn't it
> calling setLocation() on the popup's existing
> location?

Again no. But my sloppiness made it a bit difficult to see in this snippet - the getPopupLocation returns a location so that the popup overlaps the tray. Then popup.show() locates the popup at a position where it does not overlap with the tray and the moving of the ancester window pushes it into the originally desired postion overlapping the tray. The flicker is reduced (in perception) because the distance between the first show and the window re-location is small (the first show already is very near to the desired position)

Jeanette

cowwoc
Offline
Joined: 2003-08-24

Jeanette,

I tested the behavior you mentioned without any native manipulation and the popup still went away. I am pretty sure you are using JDK 1.4 and I am using JDK 1.5 which would explain the different behavior.

My code reads:

Dimension preferredSize = activeMenu.getPreferredSize();

menuRoot.setSize(preferredSize.width, preferredSize.height);
menuRoot.setVisible(true);

// newPosition overlaps the taskbar
Point newPosition = menuRoot.getLocation();
activeMenu.setLocation(menuRoot.getLocation());
menuRoot.setLocation(activeMenu.getLocation()); // position of JPopupMenu -- not covering taskbar
activeMenu.setVisible(true);

// Now move to overlap taskbar
menuRoot.setLocation(newPosition);

// JPopupMenu disappears before this line

Removing the last line fixes the popup getting dismissed but I *need* to move it :)

cowwoc
Offline
Joined: 2003-08-24

BTW, on the topic of replacing toFront() by requestFocusInWindow() for the invoker of the JPopupMenu:

menuRoot.isFocusableWindow()=true
menuRoot.isDisplayable()=true
menuRoot.isVisible()=true
menuRoot.requestFocusInWindow()=true
menuRoot.isFocusOwner()=false

It is worth noting that toFront() works and requestFocusInWindow() does not although I have no idea why. If anyone has any ideas how to further investigate this issue please let me know.

mthornton
Offline
Joined: 2003-06-10

> 1b) The ability for JNLP files to specify JVM
> arguments

From "Enhancements to
Java Web Start in J2SE 5.0":

"VM arguments: A JNLP file can now request arbitrary arguments to the virtual machine. Previous JNLP applications could only use the initial-heap-size and max-heap-size arguments to the j2se element; now a java-vm-args argument has been added. Java Web Start will honor the requests for any normal java and -X arguments that it considers "safe". A list of all such arguments will be included with each release so that the JNLP Spec does not need to change."

cowwoc
Offline
Joined: 2003-08-24

mthornton,

Yes, I am aware of the new JWS "VM arguments" parameter but note that "-Xbootclasspath" is not listed as a supported argument. Quite unfortunate, that, since in my eyes a normal application should be treated as identical to a signed JWS application. That is, you should be able to pass *any* JVM parameters to a signed JWS application.

Gili

zander
Offline
Joined: 2003-06-13

> 1) If I use a JPopupMenu with no invoker: I make the
> JPopupMenu visible, but then keyboard navigation does
> not work. The owner window has isFocusableWindow()
> set to false and invoking setFocusableWindow(true)
> does not change anything. Without this window being
> focusable, keyboard navigation does not work and I
> absolutely need it to work.

Is you root-component (or your popup even) a focus-cycle root? Does it have a focusManager?
Try these two options.
Also try JDK1.4 since the focussing of popups in 1.5 is quite broken (well, at least on X11 it is)

A silly idea that just might work; put a JFrame of the same size directly behind your popup so you actually can have a visible parent.

Also be aware that each and every window Java opens needs a frame as a parent. Opening a dialog without a parent leads to java opening a Frame which is invisible as well.

> 2) If I use a JPopupMenu with an invoker: I make the
> invoker visible, then the JPopupMenu visible, then
> call toFront() on the invoker to give it focus. Now
> keyboard navigation works -- toFront() was required
> to make this possible. The problem is that now I
> would like to reposition the invoker such that it
> covers the taskbar. As you recall, it is impossible
> to make set JPopupMenu's location such that it covers
> the taskbar; the "popupPostionFixDisabled" property
> makes this impossible. So what I do is display the
> JPopupMenu, then move the underlying window that is
> containing it. This works fine *except* the
> JPopupMenu closes itself, as if someone clicked on it
> or something. So I'm stumped.

In 1.5 the AWT guys had the brilliant idea to close a popup when either the popup or its parent looses focus; this is naturally very wrong so I suggest to work with 1.4 to 'fix' this.
You can try to remove focus-listeners on your popup window or and/or your parent frame.

Also; instead of the toFront() try a requestFocus() on either the component or the Window.

> I believe that if I could just display the JPopupMenu
> in the correct position to begin with (by modifying
> popupPostionFixDisabled to true) then I could get
> everything working. However, I don't want to modify
> this property globally because other JPopupMenus are
> not taskbar popups and I may not modify their
> behavior. Even if I was willing to change this
> behavior globally (which, again, is far from ideal)
> setting this property using
> "-Djavax.swing.adjustPopupLocationToFit=false" is not
> an option because, as mentioned before, Java Webstart
> won't allow one to set JVM command-line options for
> my application.

Did you try to set the requested property using reflection? It would work in java webstart, but only as a fully-priviledged application unfortunately.

> I would like to close by adding that I plan on
> contributing my library to JDIC in the hopes that
> others will benefit from it. I hope Sun will show its
> commitement to supporting grass-root projects such as
> this.

Let this forum know if you actually manage to get your library in; I'd be very surprised if you manage to get it committed.

Thomas Zander (who is not Sun ; )

cowwoc
Offline
Joined: 2003-08-24

Zandar,

> In 1.5 the AWT guys had the brilliant idea to close a
> popup when either the popup or its parent looses
> focus; this is naturally very wrong so I suggest to
> work with 1.4 to 'fix' this.
> You can try to remove focus-listeners on your popup
> window or and/or your parent frame.

This is actually the correct behavior (closing the popup when it loses focus) and I'm glad they added it because it is consistent with how popups work under win32. The problem is that they did not document how they did this. See, in my case all I needed to know is that the JPopupMenu has a focus-listener handling this behavior. Had I known, I would have temporary disabled it, move the popup, then reenabled it. Thanks for your help!

BTW: I've filed 4 bugs against JPopupMenu in the past day. Once closed, JPopupMenu should act more like native popups under win32; whether used as a lightweight or heightweight component.

I can only hope Sun actually delivers on its promises and takes these bug reports seriously. I even went as far as including source-code in each report. All they need to do is use the code :)

Gili

cowwoc
Offline
Joined: 2003-08-24

Zandar,

I tried locating the listeners you mentioned but could not find any. I have no idea (even looking at the source of JPopupMenu) how they dismiss the menu automatically. I believe this behavior is correct (at least under Win32) but it's incorrect that moving the menu or its underlying container causes it to be dismissed. That should not be modifying its focus... I will try rewriting JPopupMenu at runtime and see if that approach works.

Gili

kleopatra
Offline
Joined: 2003-06-11

> least under Win32) but it's incorrect that moving the
> menu or its underlying container causes it to be
> dismissed.

Again, that's not the behaviour I see: the "normal" (meaning: not natively manipulated) popup is _not_ dismissed if the underlying container is moved (neither in 1.5 nor in 1.4, under win2k using the default LF, having an invoker != null - what else might be relevant?)

Jeanette