0

I am working on an application that will have the following feature:

  • The application will have a "Load Image" button to open an image and settings modal dialog. It will need to block until that dialog returns, either with the results of the processing or null if the user changed his mind.
  • The image and settings dialog will allow the user to select an image using a JFileChooser dialog and to specify to what level of detail to process the image. Clicking a "Load" button will open a load dialog.
  • The load dialog needs to be a custom-designed dialog that reports in detail about the time-consuming processing of the image. If the user allows the processing to finish, it needs to close and return the object back to the original dialog, which needs to close and return that object back to the application. If the user decides it is taking too long to perform the processing, he can cancel the load, closing the loading dialog and returning to the image and settings dialog.

Conceptually, this does not seem so difficult to me. However, when I try to determine how to get this to work within Swing, somehow I cannot put it together. From what I've read, GUI components need to be instantiated in Swing's event thread since many of them are not thread-safe. These same components need to block on calls similar to (but not the same as, since I need to write custom components) the JOptionPane.showInputDialog() methods. But these calls need to instantiate new components in the event thread and wait for events to occur in the event thread before returning a value to the application. Compounding this with the fact that I need a dialog to pop up from a dialog, I feel quite lost.

I have read the Java Tutorial on dialogs and several posts on StackOverflow and other sites trying to determine how I can design classes that work correctly. Somehow, I just don't understand how this can work at all (isn't the event thread going to sleep after the first blocking call?), and how I can write the custom classes I need to make this work. Frankly, I am not certain I understand my confusion enough that I was able to explain it.

Could someone please explain what goes on under the hood when modal dialogs have been instantiated? How I can write dialog classes that behave the way I need as described above?

Hovercraft Full Of Eels
  • 283,665
  • 25
  • 256
  • 373
sadakatsu
  • 1,255
  • 18
  • 36

2 Answers2

2

The application will have a "Load Image" button to open an image and settings modal dialog. It will need to block until that dialog returns, either with the results of the processing or null if the user changed his mind.

OK, so this dialog will need to be modal. That much we know.

The image and settings dialog will allow the user to select an image using a JFileChooser dialog and to specify to what level of detail to process the image. Clicking a "Load" button will open a load dialog.

OK, so the load dialog will need to be modal off of the image and settings dialog. No biggie there either.

The load dialog needs to be a custom-designed dialog that reports in detail about the time-consuming processing of the image. If the user allows the processing to finish, it needs to close and return the object back to the original dialog, which needs to close and return that object back to the application. If the user decides it is taking too long to perform the processing, he can cancel the load, closing the loading dialog and returning to the image and settings dialog.

OK, so the load dialog code will need to instantiate and execute a SwingWorker to do the time-consuming image processing in a background thread, and then have the SwingWorker use its publish/process method pair to push information about the processing details back to the load dialog.

...From what I've read, GUI components need to be instantiated in Swing's event thread since many of them are not thread-safe.

Correct.

These same components need to block on calls similar to (but not the same as, since I need to write custom components) the JOptionPane.showInputDialog() methods.

And this is what a modal JDialog allows you to do. Another option to keep in mind is to use a JOptionPane and pass in a JPanel with whatever GUI you want the JOptionPane to display. JOptionPanes are surprisingly flexible and useful.

But these calls need to instantiate new components in the event thread and wait for events to occur in the event thread before returning a value to the application. Compounding this with the fact that I need a dialog to pop up from a dialog, I feel quite lost.

Again it's simple. The load dialog will call a SwingWorker which will communicate back to the load dialog.

Could someone please explain what goes on under the hood when modal dialogs have been instantiated?

Now you may be asking a bit too much for the volunteers on this site to do, since this question would probably require someone to write a complete tutorial to answer, and it has been asked and answered before, so the information should be discoverable by you. If you really want to see what is going on under the hood, you should first do the preliminary research on the subject yourself, look at the source code, and if still stuck, ask a much more specific and answerable question after first doing your own due diligence work.

Hovercraft Full Of Eels
  • 283,665
  • 25
  • 256
  • 373
  • -1. Most of your answer is repeating or reiterating what I wrote, and what I wrote is based upon two days of reading tutorials and documentation. Following that up by refusing to answer my actual question with "go do research" means (at best) that you should have made a comment, not posted an answer. – sadakatsu Oct 18 '14 at 19:58
  • @sadakatsu: I'm sorry that you didn't think any of my post was helpful. The main point I wanted to get across was the use of a SwingWorker for the background threading work, something I didn't see mentioned in your post at all. Regarding my recommendation for you to do research, well, the last part of your question was very broad, even you have to admit this, and to adequately and fully answer it, I would have to extensive research first, but why should I or any of us do so. It's your project and your question, we are all volunteers, and so the onus of effort should be yours. – Hovercraft Full Of Eels Oct 18 '14 at 20:15
  • @sadakatsu: ... continued... if you had done preliminary research prior to asking your question, then you could have asked much more specific and pointed questions regarding the mechanisms behind dialog modality, and you would likely get answers that would satisfy you better. But whatever. – Hovercraft Full Of Eels Oct 18 '14 at 20:16
  • First, I will concede that "look at the source code" was helpful. It irked me that I had not thought of that myself, and it shows my lack of maturity as a person and a programmer that I let that irritation affect my response to you. Second, I will concede (and even agree) that it is no one else's responsibility to FIND the answer for me; my hope was that someone already had it. Third, while I appreciate your trying to be helpful with the `SwingWorker` information, I did not ask about it because that was in the tutorials I had read... it was not part of my problem. – sadakatsu Oct 18 '14 at 21:07
  • @sadakatsu: then what is your question? If it is one of mainly how modal dialogs work, then the question is too broad and should be closed. If it is something else, then please clarify it for me. – Hovercraft Full Of Eels Oct 18 '14 at 21:08
  • ... continued ... Ultimately, you had some useful information, but not an answer to the question. Posting an "answer" that doesn't address the question lowers the quality of SE as much as a bad question (which I might agree my question is). It would have been better to post comments to ask clarifying questions or to vote to close the question directly rather. – sadakatsu Oct 18 '14 at 21:09
  • My question is a bit broad. It is, "How do modal dialogs work in Swing?" This information is essential for trying to create custom `JOptionPane` subclasses. The tutorials said that it can be necessary to do this, but provided no examples. So if you think the question should be closed, I am okay with that. – sadakatsu Oct 18 '14 at 21:12
  • @sadakatsu: I'm neither here nor there regarding closing it. It's not that important in the grand scheme of things. – Hovercraft Full Of Eels Oct 18 '14 at 21:17
0

Modal dialogs started from the primary event loop spawn a secondary event loop that remains active while the primary loop is blocked. See java.awt.SecondaryLoop.

Oblok
  • 1