I have got a GUI design problem which I would get help on. Suppose I have an desktop app. The app has a main window(JFrame). In the main window, there is a JButton. After clicking the JButton, the app would run some heavy execution which may take one or two minute to complete. While the execution is running, the window and UI controls will become not responsible because the execution is running on the same thread with the JButton's action thread. Therefore I thought it would be a good idea to show a JDialog with a waiting message before starting the execution. When the execution has finished, the thread can close/dispose the JDialog waiting screen. The JDialog has parent of the main window so it can block off any input directly to the main window. The JDialog also has got its close button disabled so users are not able to close the JDialog while the execution is running.
Here is what I do (not exact code):
Now the problem is, the dialog comes up and the thread is waiting for the users to close the dialog to continue, but because the close button is disabled, the thread is halted. So basically the thread got stuck and runExecution() is never run!
I am just wondering how would an experienced GUI developer would write their loading screen. Personally, I think I could solve the problem by creating another thread to handle the dialog waiting screen, but I really want to avoid creating additional thread where possible. My app's threading is messy enough but just about manageable. I don't want to make it worse.
Sorry to disappoint you but there is no way to do this in the edt. Even if you do manage to show the dialog, the heavy duty code is still executed inside the edt in which ALL of the gui is drawn so it will become unresponsive until it is finished.
Use a SwingWorker at least thats what they are for. ;)
Manuel's advice is correct, but maybe he forgot to mention that you must ensure that all GUI updates (i.e. Swing methods) are called on the EDT. If from a background Thread, that would be by wrapping them in a SwingUtilities#invokeLater(...) / invokeAndWait(...)
There are no new questions, but there may be new answers.
Joined: Jul 25, 2011
Ah! Both of your replies are inspiring to me! I should move on and experiment with these methods. Thank you.