Hey,
what i notice is that if i have a JMEDesktop with some JTextfields - i'm able to type correct when the app is started.
But - when i use ALT+TAB to switch to another programm/process and back to my jmeApp again, typing into the JTextfields is impossible. They don't accept any of the typed chars.
Although the normal movement within the scene by WASD/Cursors still works fine.
You can verify this by running the jmetest.awt.swingui.TestJMEDesktop
May someone verify this quickly, please :? ?
I'm running on WinXP and Java 1.6.0_11…
ok, thx
verified 
hm, it seems that there is no problem if i just have a "pure" swing application.
Has someone a clue where this bug might come from?
I don't think it's within the java source code, but maybe somewhere in the JMEDesktop or the Inputhandling code.
It's not that important but annoying… you run the programm, switch to the console and back again… and damn!! All textfields are blocked again. even if they are not active at the time of switching the process…
ok, by checking the JMEDesktop.setFocusOwner() it seems that the textfields get the focus correct. They are even enabled and editable.
edit
checking the JMEDesktop.onKey() and JMEDesktop.sendAWTEvent() methods… the textfields definitely get the events but aren't using them?!
It really have to be something connected to the Inputhandling somehow…
…Does anyone of you guys know how the KeyboardInput is handled within swing components?
I know there are KeyEvents whiche are normally send to the EventQueue or are dispatched to the Component directly.
What is really strange too is, that if i don't use ALT+TAB to switch the process but the Windows-Key and click to another window then its working fine. 
what happens to a jme window if i hit ALT+TAB?
Hey JOC,
thx man.
I've verified this workaround!
It was strange, because the problem doesn't arise in java 1.5…
anyway, good to know there is an easy workaround.
The keyIndex used in the JMEDesktop.sendAWTEvent(…) is correct, even for the ALT key.
BTW: In the class
com.jmex.awt.input.AWTKeyInput
line 370 and 371 might be changed to
case KEY_RMENU:
return KeyEvent.VK_ALT_GRAPH; //todo: location right
Seems this is a old problem on and off - http://www.jmonkeyengine.com/jmeforum/index.php?topic=7619.msg60014#msg60014
I have found a kinda cludgy solution by modifying the update method in LWJGLKeyInput.java. Im not sure how safe this is as I don’t know why or where Display.isActive() might return false - but assuming thats only when the JME app doesn’t have focus, this should be safe.?..?..?.
Someone please let me know if im wrong . . . (or if im right - other characters that might need adding)
/**
* <code>update</code> updates the keyboard buffer.
* @see com.jme.input.KeyInput#update()
*/
public void update() {
/** Polling is done in {@link org.lwjgl.opengl.Display#update()} */
if (Display.isActive()) {
while ( Keyboard.next() ) {
char c = Keyboard.getEventCharacter();
int keyCode = Keyboard.getEventKey();
boolean pressed = Keyboard.getEventKeyState();
keyState[keyCode] = pressed;
if(listeners != null && listeners.size() > 0) {
for ( int i = 0; i < listeners.size(); i++ ) {
KeyInputListener listener = listeners.get( i );
listener.onKey( c, keyCode, pressed );
}
}
}
}
else {
// clear events - could use a faster method in lwjgl here...
while ( Keyboard.next() ) {
//nothing
}
// If display isn't active, clean up control character keypresses.
// This is primarily to stop the ALT key remaining pressed when you ALT-TAB
// out of a JMEDesktop app (on Windows) and ALT-TAB back into it again.
keyState[KeyInput.KEY_LMENU] = false; // Left ALT
keyState[KeyInput.KEY_LCONTROL] = false; // Right ALT
}
}
ok, verified your fix.
It's working - i can't tell if it's save.
And a little correction:
it should be KEY_RMENU for the right ALT key.
keyState[KeyInput.KEY_LMENU] = false; // Left ALT
keyState[KeyInput.KEY_RMENU] = false; // Right ALT
thx so far
Hmmm - am at work now neck deep in SQL :’( . . .
I think I tried using KeyInput.KEY_RMENU first (seeming the obvious option) but nothing happened with that, so I put a breakpoint in the code above where my patch was and saw what the value was after pressing the key (0x19 if I remember correctly) so looked for the matching constant in KeyInput - and that one worked for me. Maybe its a keyboard/OS issue and there are multiple ones that match - I don’t know tho, thats why I asked for other opinions (I dont have a dev environment on my mac and no Linux installed atm either).
Will double check when I get home later tho.
Have checked, and it seems I get 2 keycodes sent for the right alt key -
KEY_LCONTROL (0x1D) followed by KEY_RMENU (0xB8)
Just clearing the KEY_RMENU on its own doesn't work for me, but clearing the other one on its own does…?!?