Clever Geek Handbook

Java window buffering keystrokes until user clicks

Here's the basic idea:

There is a java window (main) which opens another java window (child). When the child is created, the initialization part sets focus to the corresponding text box in the child window:

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

The child usually opens up through serious keystrokes through a command line type interface. When a window is requested, 90% of the time, focus correctly goes to the child window's text box and the user can enter it in the box. If a command to open a child is sent (by pressing enter) and the user immediately starts typing before a new window is created, the text will be properly buffered and appear in a new text box after the window is opened.

However, every time the user requests the child window to open and then starts typing, their text is NOT displayed in the text box. Only after clicking the mouse, the text they typed appears in the field. It is somehow stored somewhere and doesn't come out until it clicks.

The real frustrating thing here is that I cannot confidently reproduce the problem at all. It definitely happens, but not regularly enough to debug well.

There are, of course, all sorts of other mojo going behind the scenes, including communicating with the server application, but I'm not sure if this is related.

Any thoughts or ideas would be much appreciated.

+1


source to share


4 answers


At first glance, this sounds like an implementation bug; the key must be in the same event queue as the mouse events. One more problem is possible: the event queue is started in a thread separately from the main program; Without knowing what is happening in the rest of the application, it is tempting to think about the event queue thread being blocked in some way.

In fact, the complexity you face when playing it makes this sound even more likely.



Debugging this case requires a bit of craft and trickery. If you are using Solaris 10 or OS / X, I would recommend using dtrace; you can easily put a tracepoint in the event queue. But no, you might want another thread to periodically put something on the event queue.

0


source


I had a problem similar to this. try adding this afterinit() 

EventQueue.invokeLater(new Runnable() {
    public void run() {
        childtextfield.requestFocus();
        childTextField.setCaretPosition(0);
    }
});


This worked for me.

+1


source


The event blocking thread is being blocked by sounds VERY probable. Unfortunately I'm on windows so don't want to for me, but I'll definitely investigate this in more detail.

Of course, anyone with other ideas would be very happy.

0


source


It turns out that the answer was not so interesting. After you mentioned the event queue, I dug into the code a bit. It turns out the app has a customizable keyboard focus manager. It will do things like buffer, typed text, waiting for a child window to open. In the code to open the child window, it calls a function (via a listener) that clears the buffer and displays it on the screen. This does not happen for 10% or less of the time. However, the same flash function is also attached to mouse clicks that occur inside text boxes. So you guessed it didn't work with opening the window, but when the mouse clicked.

Thanks for the help ... although it wasn't exactly what the solution was, it definitely pointed me in the right direction. Now I just need to figure out why the flush function is not always called when the window opens ...

0


source






More articles:


All Articles