Daniel Pitts wrote:
Hal Vaughan wrote:
Daniel Pitts wrote:
All interaction with Swing components should be done on the Event
Look at the class SwingUtilities
specifically the invokeLater() method
Instead of setting aFlag, you should simple fire an event on the EDT.
Even if you wanted to wait for the flag to change, you need to use
synchronization. You also shouldn't be using a busy wait (even if you
sleep for 50), but instead do something like this:
[snip my code]
Thanks -- good examples and code and points to ponder.
It would seem to me I might be able to make it a bit simpler. This class
is supposed to be a simple "Please Wait..." window that I can customize
flash up during longer operations. I might do it with a JOptionPane, but
also need to understand this situation anyway. I've tried using
invokeLater before and had some problems getting it to work.
Instead of having any "aFlag" or "active" or any other variable, can't I
do something like this:
That would provide simple methods to both open and close the window.
The CPU cycle using activities are in another class. I was trying to
make this class a simple one that I could set up in a couple lines and
call without having to create separate threads or anything like that --
in other words, the class itself would create any needed Runnable or
The calling code would look like this (assuming this class name is
WaitDialog wd = new WaitDialog();
//Follow with settings for wd here
It seems to me that would still do everything the same way as what you're
talking about in the same way, just that the extra typing of creating a
Runnable() is in the WaitDialog class so all I have to do is call it with
two calls instead of creating a Runnable each time I use it.
Is that reasoning correct? If it is, I'm still having trouble getting it
to work, but I'd like to know if I understand this correctly first.
That seems like a good approach to me, the only thing I would watch out
for is to make sure your calls to "activate" and "deactivate" *don't*
occure on the EDT, otherwise your doExtensiveThings is going to block
the EDT, and your window won't show up.
Thanks! I'm beginning to get a feel for this.
If activate() and deactivate() have separate threads within them, won't that
take care of that? In other words, the EDT thread calls activate(), and
within activate() I use SwingUtilities.invokeLater() and put the thread in
there to update the GUI? That would still be using a different thread, but
just within the method called instead of outside. It may not be much of a
difference, but it would make the coding when I use that class easier.
Also, as I've experimented, I've found that if I put any GUI updates within
a Runnable() that is called with SwingUtilities.invokeLater(), those
functions are not done until after the doExtensiveThings() routine is
called. What do I do if I want to update the Swing GUI, THEN
doExtensiveThings(), then update the GUI again? It seems invokeLater()
does such a good job at invoking later all GUI work that it calls is held
until the other stuff is done. That makes it hard if I want to start with
a message to the user saying, "This could take a while, please wait..."
Is there a way to repaint/refresh the GUI first, then do the work?
This is how you do it.