• Post Reply Bookmark Topic Watch Topic
  • New Topic

SwingWorker and Modal JDialogs  RSS feed

 
Ted Smyth
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good Afternoon all,

I've developing a Swing app, and I need to conduct a lengthy database operation in the background while a modal dialog shows an indeterminate progress bar.

Something I've noticed is that if the JDialog is modal, then the SwingWorker will not execute its tasks until the JDialog is closed (and releases its deathgrip on the EDT, I guess...?). If the JDialog is not modal, then SwingWorker's tasks will execute happily in the background.

I've been doing some research, but I'm no thread/EDT expert and am having a hard time figuring the reason/solution.

Any input on this situation/threads/EDT/SwingWorker, or a suggested solution, would be greatly appreciated.

Cheers & Regards
 
Ted Smyth
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Additionally:

I've noticed that this only occurs when extending JDialog... Hmm.
 
Ted Smyth
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well I found a workaround where I simply decorate the JDialog as I please without extending it.

Strange though that a custom JDialog blocks the SwingWorker threads from execution... A thought for another day I guess.
 
Nathan Pruett
Bartender
Posts: 4121
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Swing achieves modality by blocking the event thread for any events for components outside the modal dialog.

How are you extending JDialog in the cases where it doesn't work?
 
Ted Smyth
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's my extended dialog:



The TestTask object extends SwingWorker, and closes the dialog (setVisible(false)) in done().

Looking at this now, I'm thinking that perhaps I should reverse the placement of setVisible(true) and task.execute()... hm.
 
Darryl Burke
Bartender
Posts: 5167
11
Java Netbeans IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Looking at this now, I'm thinking that perhaps I should reverse the placement of setVisible(true) and task.execute()... hm.

Hm indeed

I also feel that invoking setVisible(true) from the constructor is bad practice as you are attempting to show an incompletely constructed object. It may be better for the calling routine to set the dialog visible. This call should be made on the EDT.
 
Ted Smyth
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Darryl Burke:

Hm indeed

I also feel that invoking setVisible(true) from the constructor is bad practice as you are attempting to show an incompletely constructed object. It may be better for the calling routine to set the dialog visible. This call should be made on the EDT.


I would argue that the super constructor does all of the real dialog construction, and so setVisible is harmless, but I believe you're right on principle, if not technically as well!

I suppose that JOptionPane.showXXX(...) constructs a dialog and then shows it, effectively what you suggest.

Thanks for the input Darryl! Much appreciated. I will fiddle with it this weekend and post some results.
 
Darryl Burke
Bartender
Posts: 5167
11
Java Netbeans IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would argue that the super constructor does all of the real dialog construction


You're correct, I should change the way I think about it. Thanks.

However, GUI-updating code should always be queued on the EDT via SwingUtilities / EventQueue # invokeLater, so if setVisible(true) is called in the constructor, I believe the construction of the object [new ...()] should be similarly queued.

I've seen a lot of problems solved by changing the code to wrap a call to setVisible(true) in an invokeLater after the constructor returns.
 
Rob Spoor
Sheriff
Posts: 20898
81
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Of course invokeAndWait is also an option.
 
Ted Smyth
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dialog works great now.

In retrospect, it is *REALLY* obvious that calling setVisible(true) before executing the task would prevent the task from executing. Heh. EDIT: I also took your suggestion to heart Darryl and moved the setVisible() invocation to the calling procedure instead of in the constructor.

Thanks again for the input guys and helping me further wrap my head around Swing, modality, and the EDT.

Cheers & Regards,
[ June 09, 2008: Message edited by: Ted Smyth ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!