Applications do not react to input if the window is generated while out of focus.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open a blacken example.
2. Before the window appears, change focus to another window.
3. Try to use the keyboard for input.

What is the expected output? What do you see instead?
It should react to the input, but doesn't.

Please use labels and text to provide additional information.
This has been an issue with libjcsi as well. It can be critical if the 
application has a longer loading time, with many people doing something else 
while waiting for the window to pop up.

This may or may not be related to my platform - I'm running a x64 Win7 with 
JDK7u6.

Original issue reported on code.google.com by tau_i...@live.de on 24 Aug 2012 at 9:21

[GoogleCodeExporter]

This sounds like a problem.

Surely this can't be a general Java issue -- if it was it would be reproducible 
with Eclipse and Netbeans. Those things take a long time to load...

I wonder if you can mitigate the issue with a splash screen...

Original comment by yam...@gmail.com on 24 Aug 2012 at 9:44

[GoogleCodeExporter]

Original comment by yam...@gmail.com on 24 Aug 2012 at 9:45

• Added labels: Milestone-Release1.1

[GoogleCodeExporter]

If you saw this with the JNLP load then a splash screen won't help. The JNLP 
loading process has a built-in splash sscreen

Original comment by yam...@gmail.com on 25 Aug 2012 at 12:28

[GoogleCodeExporter]

A little update: It seems to be only the key input that doesn't work. It 
registers and reacts to resize events just fine.

Original comment by tau_i...@live.de on 25 Aug 2012 at 9:38

[GoogleCodeExporter]

I know what is going on enough that I have a work-around.

The focus is somewhere weird. I don't know where it is, as the frame's pretty 
simple, a JFrame and a single Panel, but something has the focus.

I tried both explicitly saying the BlackenPanel should never have focus as well 
as saying that that it has the same (standard) KeyListener -- no change in 
behavior.

I explicitly say the BlackenPanel should have the focus in the init function. 
No change.

At this point I have to think it is by design. Like there's an explicit "null" 
component that is given focus if the window doesn't have focus at some point.

I have a number of work-arounds in place now.

Strictly speaking, the problem is still there. However, if you move the window, 
resize the window, give the window focus, or move the mouse in to the window it 
self-corrects. 

The problem is that every time I think I know the perfect place to add the 
work-around so as to prevent the problem from ever appearing, I find that the 
focus was changed after that function has run.

Original comment by yam...@gmail.com on 26 Aug 2012 at 5:24

[GoogleCodeExporter]

So, I added support for checking for key input without blocking with two 
functions in my latest check-in. Using these functions you should be able to 
watch for input but otherwise work performing an animation. (The goal would be 
something like the Brogue splash screen.)

If something like that is done in a game, it should fix this issue before the 
user ever sees it. Both of the functions I added detect and correct this issue.

Original comment by yam...@gmail.com on 26 Aug 2012 at 6:14

[GoogleCodeExporter]

XLambda,

Have you checked my solution out? I know it's not perfect, but is it good 
enough to close the ticket? (... with the caveat that there is a note about it 
in the FAQ.)

I know what's going on, but at this point I'm stumped as to how else to fix it. 
It's as if after the window is created (and may be waiting for key input) Java 
comes along and says, "Hey, not so fast. You don't have focus." Then takes the 
focus away without assigning it to any other component.

I'm sure it made sense to someone doing traditional GUI development where you 
expect someone to start things off with their mouse. (I did fix it so that as 
soon as the mouse enters the window it's all square.) It's just... with a 
Roguelike game and keyboard controls you don't expect to need to explicitly 
assign focus to a component.

Original comment by yam...@gmail.com on 28 Aug 2012 at 4:39

[GoogleCodeExporter]

The solution works well as far as I can see. Good work!

Original comment by tau_i...@live.de on 28 Aug 2012 at 6:34

• Changed state: Fixed

[GoogleCodeExporter]

Something really crazy: I just saw this happen with the Windows 7 "cmd.exe" 
program. This appears to be a general Windows issue and the "fix it when they 
click it" approach appears to be the common one.

Original comment by yam...@gmail.com on 23 Jan 2013 at 3:00