Клавиши буферизации окна Java, пока пользователь не щелкнет мышью

Question

Вот основная идея:

Существует окно Java (основное), которое открывает другое окно Java (дочернее). Когда дочерний элемент создан, часть инициализации устанавливает фокус в соответствующем текстовом поле в дочернем окне:

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

Ребенок обычно открывается с помощью серьезных нажатий клавиш через интерфейс типа командной строки. Когда окно запрашивается в 90% времени, фокус правильно переходит к текстовому полю дочернего окна, и пользователь может ввести его в поле. Если команда на открытие дочернего элемента отправляется (нажатием клавиши ввода), и пользователь сразу начинает вводить текст перед созданием нового окна, текст корректно буферизуется и появляется в новом текстовом поле после открытия окна.

Однако, время от времени, когда пользователь запрашивает открытие дочернего окна и затем начинает печатать, его текст НЕ появляется в текстовом поле. Только после того, как они щелкнут мышью в поле, текст, который они ввели, появляется. Как будто он где-то хранится и не выходит, пока не щелкнет.

Реальное разочарование здесь в том, что я не могу точно воспроизвести проблему. Это определенно происходит, но не достаточно регулярно, чтобы хорошо отлаживать.

Конечно, за кулисами происходят все виды других моджах, включая общение с серверным приложением, но я не уверен, что это связано.

Любые мысли или идеи будут очень цениться.

Answer 1

У меня была проблема, похожая на эту. попробуйте добавить это после вашего init()

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

Это сработало для меня.

Answer 2

Оказывается, ответ не был таким уж интересным. После того, как вы упомянули очередь событий, я немного углубился в код. Оказывается, в приложении есть собственный менеджер фокусировки клавиатуры. Это будет делать что-то вроде буфера текста, набранного в ожидании открытия дочернего окна. В коде, открывающем дочернее окно, он вызывает функцию (через слушателя), которая очищает буфер и таким образом отображает его на экране. В те 10% или меньше времени этого не происходит. Однако та же самая функция сброса также прикреплена к щелчкам мыши, которые происходят внутри текстовых полей. Итак, как вы уже догадались, оно не вспыхнуло при открытии окна, а произошло при нажатии мыши.

Спасибо за помощь ... хотя решение было не совсем, оно определенно указало мне правильное направление. Теперь мне просто нужно выяснить, почему функция flush не всегда вызывается при открытии окна ...

Answer 3

Поток очереди событий кажется ОЧЕНЬ вероятным. К сожалению, я нахожусь на окнах, так что нет никаких следов для меня, но я определенно собираюсь изучить это более тщательно.

Конечно, всем, кто мог бы иметь другие идеи, был бы очень рад.

Answer 4

На первый взгляд это звучит так, как будто это может быть ошибкой в ​​реализации; ключ должен находиться в той же очереди событий, что и события мыши. Однако возможна еще одна проблема: очередь событий выполняется в потоке, отдельном от основной программы; не зная, что происходит в остальной части приложения, возникает соблазн задаться вопросом, не блокируется ли каким-либо образом поток очереди событий.

На самом деле, трудности, возникающие при воспроизведении, делают этот звук еще более вероятным.

Для отладки этого случая потребуется немного хитрости и хитрости. Если вы используете Solaris 10 или OS / X, я бы порекомендовал использовать dtrace; Вы можете легко поместить точку трассировки в очередь событий. В противном случае вам может понадобиться другой поток, который периодически что-то отбрасывает в очередь событий.