tags:

views:

193

answers:

4

Here's the basic idea:

There is a java window (main) that opens another java window (child). When the child is created, part of the initialization sets the focus in the appropriate text field in the child window:

childTextField.requestFocusInWindow();
childTextField.setCaretPosition(0);

The child is generally opened through a serious of keystrokes via a command line type interface. When the window is requested, 90%ish of the time, the focus correctly goes to the child window text field and the user can type in the box. If the command to open the child is sent off (with a press of the enter key) and the user immediately starts typing before the new window is created, the text is correctly buffered and appears in the new textfield after the window opens.

However, every once in a while when the user requests the child window to open and then starts typing, their text does NOT appear in the text field. Only after they click with the mouse in the field does the text they have typed appear. It's like it's being stored somewhere and doesn't come out until they click.

The real frustrating thing here is that I can't seem to reliably reproduce the issue at all. It definitely happens, but not regularly enough to debug nicely.

There is of course all kinds of other mojo going on behind the scenes, including communication with a server app, but I'm not convinced it's related.

Any thoughts or ideas would be very much appreciated.

A: 

On first look, that sounds like it might be a bug in the implementation; the key should be in the same event queue as the mouse events. There's another issue possible though: the event queue is running in a thread separate from the program main; without knowing what's going on in the rest of the application, it's tempting to wonder if the event queue thread is getting blocked somehow.

Actually, the difficulty you're having with reproducing it makes that sound even more likely.

Debugging that case will require a little craft and trickery. If you're on Solaris 10 or OS/X, I'd recommend using dtrace; you can easily put a trace point on the event queue. In not, you might want to have another thread that periodically drops something on the event queue.

Charlie Martin
A: 

The event queue thread being blocked sounds VERY likely. Unfortunately I'm on windows, so no dtrace for me, but I'm definitely going to explore that more thoroughly.

Of course anybody else who might have other ideas would be very welcome.

Morinar
+1  A: 

I had an issue similar to this. try adding this after your init()

print("

 EventQueue.invokeLater(new Runnable() {

        public void run() {
            childtextfield.requestFocus();
            childTextField.setCaretPosition(0);
        }
 });

");

It's worked for me.

Chris Mattmiller
A: 

It turns out the answer wasn't all that interesting. After you mentioned the event queue, I dug into the code a bit more. It turns out the application has a custom keyboard focus manager in place. It would do things like buffer the text typed while waiting for a child window to open. In the code to open the child window, it calls a function (via a listener) that flushes the buffer and thus displays it to the screen. In that 10% or less of the time, that doesn't happen. However the same flush function is also attached to mouse clicks that happen inside of text fields. So, you guessed it, it didn't flush with the opening of the window, but did when the mouse was clicked.

Thanks for the help...even though it wasn't exactly what the solution was, it definitely pointed me in the right direction. Now I just have to figure out why the flush function isn't always getting called when the window opens...

Morinar
okay, that one almost certainly *is* a bug. I'd put a trace point or a call to logger.info or something like it into the focus manager as early as possible, see what the event really is, and walk through the code paths. Odds on that there's an unexpected case and a code path that doesn't flush.
Charlie Martin