Event dispatching thread: Difference between revisions

Revision as of 10:57, 7 June 2014

Revision as of 13:04, 7 June 2014

Line 88:

SwingWorker is normally created for a lengthy tasks by EDT while handling callback (Listener) events. Spawning a worker thread, EDT proceeds handling current message without waiting the worker to complete. [http://stackoverflow.com/questions/3028842/how-can-swing-dialogs-even-work Often, this is not desirable.]

Often, your EDT handles a GUI component action, which demands the user to make a choice by means of another dialog, like JFileChooser, which pops up, stays responsive while user picks its option and action proceeds with selected file only after "OK" button is pressed. You see, this takes time (user responds in matter of seconds) and you need a responsive GUI (the messages are still pumped in EDT) during all this time while EDT is blocking (it does not handle newer, e.g. JFileChooser, messages in the EDTqueue executingbefore the dialog is closed and current messagecomponent action is finished). The miracleviscous cycle is achievedbroken through EDT entering anothera new message loop, which dispatches the messages as per normal until "modal dialog doneis over" arrives and normal message arrivesprocessing resumes from the blocked position in the component action.

The open source [http://foxtrot.sourceforge.net/docs/worker.php Foxtrot] project emulates the Swing message loop pumping to provide the "synchronous" execution mechanism for arbitrary user tasks, which proceeds only after the worker completes the task.