In some cases, I have a complex and heavy swing client application that contains many modal components, jdialogs, internal frames, etc., there is a problem, and it is impossible to focus on swing text fields. You can click on some jbuttons, jcheckboxes, but it is no longer possible to focus and edit values on editable jtextfields. The gainfocus events of editable text fields are no longer triggered; when you click on text fields, only requestfocus methods are called. I found a way (hack) to solve the problem case when a problem occurs, and you show the joptionpane or modal jdialog message and close it by clicking or deleting, the problem disappears, you can click on the text fields and edit them, As a solution, I I do some checks if you try to focus on the component, I start the timer thread in the requestfocus event of the clicked text field and save it as a focusrequesting component. After a while I will check the last focused component on
KeyboardManager.getCurrentKeyboardFocusManager (). GetPermanentFocusOwner ()
If there is no problem and the text field receives focus, the returned object (retur value for getPermanentFocusOwner) is the same instance as the focusrequesting component. But if there is a question about problems, the returned object is different from the requesting focus, and I open my temporary jdialog with:
JDialog dialog=new OptionPane().createDialog(KeyboardFocusManager.getCurrentFocusManager().getActiveWindow(), ""); dialog.setModal(true); // MUST be modal to fix the lost focus case // start closing thread, which closes the dialog after some few time by dialog.dispose new Closer(dialog).start(); dialog.setVisible(true);
This mechanism works, now it is not very stable. And in some cases, the .dispose () dialog does not work, temporary windows always remain on the screen, and do not close, and since it is modal, the client can no longer do anything. The dialogue MUST be modal to solve the focus problem, since modeless dialogs do not solve the focus problem described above. There are many synchronized blocks, mutex objects, etc. in the jdialog removal method, I think that some deadlocks occur there.
Any better suggestions, ideas? I know that the best solution is to check the current application, analyze it or rewrite it. But it is very complex, heavy, and the model and presentation are poorly organized properly. I have a short time, because the client is waiting, I need temporary solutions, tricks or hacks.