• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

SwingWorker and Modal JDialogs

 
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.
 
Bartender
Posts: 4121
IntelliJ IDE Spring Java
  • 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.
 
Bartender
Posts: 5167
11
Netbeans IDE Opera Java
  • 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
Netbeans IDE Opera Java
  • 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.
 
Sheriff
Posts: 21775
103
Eclipse IDE Spring VI Editor Chrome Java Ubuntu 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 ]
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!