I need to display a non-decorated window. This is a system information window. It should behave like a modal dialog, in that the user should not be able to select any other window until I close the dialog.
The problem is that I want to display the window and then continue to do work in the GUI thread. So I need to call a method to display the window that returns immediately.
That would put the code in the wrong class. I though about providing a callback method so that the dialog could call that method to give control back to the caller but that seems really bad design and very confusing. I want to be able to write a procedure that would flow just as if the dialog was non-modal, but be able to prevent any actions on the main form.
I think I might be going about this all wrong. I was thinking that I would be putting up a system info message (like system shutdown in progress) as I have seen in a C# app. But if the work I am doing is taking long enough to need a message box, it needs to be done in a different thread so that the GUI will continue to be drawn anyway. So maybe I should be using a regular modal dialog and doing my work in a different thread.
That would put the code in the wrong class.
Not if it's an inner class.
But if the work I am doing is taking long enough to need a message box, it needs to be done in a different thread so that the GUI will continue to be drawn anyway. So maybe I should be using a regular modal dialog and doing my work in a different thread.
Yes, absolutely. You shouldn't ever perform time-consuming tasks on the EDT. Do your work on another thread and publish messages from it. Your listener (which may be the same object as produces your dialog, or an inner object of it) can hook onto the EDT and update the content of your dialog.
Your window could listen for being deactivated and activate itself again.
Modal dialogs completely block the dispatcher thread, running their own event pump restricted to events for their own heirarchy.
Even if you do the setVisible(true) from another thread it does invokeAndWait to run on the dispatcher thread.
>>It should behave like a modal dialog, in that the user should not be able to select any other window until I close the dialog.
>>The problem is that I want to display the window and then continue to do work in the GUI thread. So I need to call a method to display the >>window that returns immediately.
>>I though about providing a callback method so that the dialog could call that method to give control back to the caller but that seems really >>bad design and very confusing.
BaltimoreJohn, i got the same problem. How did you solve this this? Any good practice? Thanks.