JComboBox problem in "TestJMEDesktop"

I've been playing around with "TestJMEDesktop" and I"m noticing a strange behavior when selecting the JComboBox control in the test suite. The drop down list initially appears after clicking on the control, and then it instantly disappears before I have a chance to select anything from the list. I looked at the bug list and didn

This is a known problem if you are running JRE 1.6.  They must have changed something to do with popups in 1.6 that causes this to occur.



No one has taken the time to figure out why this is happening yet.

I have been trying to figure this out.



When playing around with JMEDesktop I almost made it work.



In the onButton method I moved the sendAwtMouseEvent() call to outside the invokeAndWait() like this:

public void onButton( final int swingButton, final boolean pressed, final int x, final int y ) {

Another thought is that it has something to do with focus and visibility. When I set the showingJFrame to true, i.e. clicking the actual component and not "manually" generating any awtEvent,

Irrisor is going to be the one that can hopefully give you some ideas of things to try.  You'll be my hero if you can get this working though. :wink:

Through some debugging I found that the problem was caused by an UngrabEvent in the awtEventQueue. While searching the net for info on how to trace events in the awt event queue I came across this: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6548397



Obviously it’s a known 1.6 bug.



I inserted this code:

Toolkit.getDefaultToolkit().getSystemEventQueue().push(

Irrisor, I didn't want to commit this code without a go-ahead from you?  Surely you read every post. :wink:

Awesome! In my setting (3d scene with JMEDesktop for UI overlays as separate render passes), Rik's fix seems to work flawlessly.

Just out of curiosity, has anybody had this problem on any OS other than Windows XP?

I've had the same problem on Vista.

I have been trying to find documentation about this sun.awt.* package but I can

Ok ,

According to the compiler warnings I get when compiling latest cvs, DisplaySystem and the collada loader's Base64 handling code rely on having sun proprietary packages installed anyway. So for now, I decided to just stick with the instanceof version, which I expect to be a bit faster than the String comparision version…

Since I never heard anything from Irrisor about this I've gone ahead and added the fix to JMEDesktop and will check it in today.

Ah, sorry just stumbled upon this thread.



This code would most probably hinder compilation on mac (as they have a custom jdk) and won't work on e.g. blackhead etc. - so I can't recommend to commit that. Can't we wait for the bug to be fixed in the jdk? (if that is really the cause)

Not really since it keeps any popups from working in JDK 1.6.



If you have another alternative that would be great. :wink:

The type check could be done with comparing the class name to a string instead (if it's no subclass :|). And the fix should be applied only for jdk 1.6.

How do you propose applying it just for JDK 1.6?

System.getProperty("java.vm.version") ?

Can you folks vote for this bug on Sun's website? It might help getting it fixed soonest! Thanks!



http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6548397

Seems like this bug is fixed now!



http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=faad97d1e6f15f7d0f1405b7680be?bug_id=6539458