[jdjlist] Re: modal,but not dialog (use Runnable in backgroun d thread)

[Tom Jordan]

mzperx wrote:             > In the meantime, I started to make a state-aware implementation test for the             > GUI components, if all else fails.   Providing user feed-back for long operations is a good thing as described in "Java Look and Feel Design Guidelines": http://java.sun.com/products/jlf/ed2/book/  (see Chapter 6 "Behavior", section: "Operational Feedback").   mzperx wrote: > Unfortunately I am not allowed to disable all buttons, fields, etc. as state-handling is > not implemented, so after the comm. ends I don't know in which state I should update > the gui automatically.   Keeping the GUI properly updated is easy if you encapsulate the "long operation" and the "GUI update" in a Runnable as shown below.   Although not explicitly mentioned in the "Java Look and Feel Design Guidelines", during long operations we desensitize UI controls that are inappropriate while the long operation is in progress (while allowing them to work in other areas). You especially want to desensitize the control that initiated the long operation in-progress, until that operation is finished (do you want to the user to start another long operation exactly the same as the one in-progress? ...almost certainly not).   All of these long operations (those that could take longer than 6 seconds) are performed in a background thread. The background thread runs a Runnable that has a run() method that look like this:       public void run() {        try {           // Perform any UI actions that should be performed before the           // work begins (for instance, change the cursor to an hourglass).           SwingHelper.invokeAndWait(new Runnable() {              public void run() {                 prepare();              }           });             // Perform the long (non-UI) operation           work();             // Display the results generated by the work() method.           // Call invokeAndWait() to prevent returning until the swing updates           // are complete. This allows a subclass to override the run()           // method with a synchronized version so the displayed results           // are always consistent with the work performed, even when the           // swing job is reused.           SwingHelper.invokeAndWait(new Runnable() {              public void run() {                 showResults();              }           });        }        catch (Exception ex) {           // Handle the exception           final Exception exFinal = ex;           SwingHelper.invokeLater(new Runnable() {              public void run() {                 exceptionHandler(exFinal);              }           });        }        finally {           // Make sure database connections and file streams are closed, etc,           // and/or change the cursor to back to the default).           SwingHelper.invokeLater(new Runnable() {              public void run() {                 cleanup();              }           });                  }     }   All you have to do is implement the prepare(), work(), showResults(), exceptionHandler() and cleanUp() methods as appropriate for your application.   -----Original Message----- From: mzperx [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 11, 2003 8:59 AM To: jdjlist Subject: [jdjlist] Re: modal,but not dialog Thank you for the quick response. Do you mean I should replace the whole GUI with a panel with a string during communication and then change it back? If so, it wouldn't make our client happy, they want the data (e.g.: search criteria) visible while communicating. L In the meantime, I started to make a state-aware implementation test for the GUI components, if all else fails.   Thank you again, Peter -----Eredeti �zenet----- Felad�: U. Penski [mailto:penski@uumail.de] K�ldve: 2003. november 11. 14:03 C�mzett: jdjlist T�rgy: [jdjlist] Re: modal,but not dialog   Hi, a short answer (I'm on the move) : look at "MSDEV\Samples\Sun\CardTest" of MS-JDK 1.0 (or newer). There the controls are put into a "panel" (class Panel). You could remove the panel as long as necessary - showing e.g. a g.drawString("busy communicating...",x,y); at its place   sincerely, U. Penski [EMAIL PROTECTED] ----- Original Message ----- From: mzperx To: jdjlist Sent: Tuesday, November 11, 2003 7:26 AM Subject: [jdjlist] modal,but not dialog   Hi,   I have a gui-related problem with a legacy-application, and I ask for your advice.   I have an applet-client, where client-server comm. might take pretty long. Now, the communication doesn't run on a separate (worker-) thread, but on the main one, which makes unwanted clicks on the buttons possible, without the user knowing it, as gui is not updated till the comm. ends, because they are all on the main event dispatching thread. As the gui isn't updated, the user might think, nothing has happened, and clicks again.And again. Unfortunately I am not allowed to disable all buttons, fields, etc. as state-handling is not implemented, so after the comm. ends I don't know in which state I should update the gui automatically.   What I was thinking about as a solution to prevent subsequent actions easily is to throw up a modal dialog telling the user that the communication has started. Since it would be modal, user would not be able to click on anything else till the modal dialog is open. Then, when comm. ends, it would make the dialog disappear. The problem is the natural way of working of the modal dialog: till it's closed, code execution halted.   Do you have any idea how could I throw up a "modal something" which is not a dialog  or achive the goal, so that: 1. gui components should not be disabled and 2. user would not be able to send actions (clicks, selection, whatever) and 3. inform user of the running communication.   To summarize it, I think it would be a temporarily non-responsive gui. We use jdk 1.3.1, so indeterminate progress bars and monitors are not available and as far as I know, they are not modal anyway.   Thanks for the help in advance,   Peter   --- You are currently subscribed to jdjlist as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] http://www.sys-con.com/fusetalk To unsubscribe from all mailing lists, click: http://sys-con.com/[EMAIL PROTECTED] --- You are currently subscribed to jdjlist as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] http://www.sys-con.com/fusetalk To unsubscribe from all mailing lists, click: http://sys-con.com/[EMAIL PROTECTED] --- You are currently subscribed to jdjlist as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] http://www.sys-con.com/fusetalk To unsubscribe from all mailing lists, click: http://sys-con.com/[EMAIL PROTECTED] THIS E-MAIL MAY CONTAIN PRIVILEGED, CONFIDENTIAL, COPYRIGHTED, OR OTHER LEGALLY PROTECTED INFORMATION. IF YOU ARE NOT THE INTENDED RECIPIENT (EVEN IF THE E-MAIL ADDRESS ABOVE IS YOURS), YOU MAY NOT USE, COPY OR RETRANSMIT IT. IF YOU HAVE RECEIVED THIS BY MISTAKE, PLEASE NOTIFY US BY RETURN E-MAIL AT [EMAIL PROTECTED], THEN DELETE. THANK YOU.