At 08:31 AM 10/24/2001 -0500, Bill Tschumy wrote: >I need to use a JProgressBar to display progress while saving a large >document. I'm running into the common problem that you need to actually >do the work outside the event thread so the progress bar will update >during the work. I have read about using SwingWorker, but this really >doesn't seem to solve my problem. > >I need to do a Save in response to a menu command. I need to ensure that >the save happens synchronously before other operations could happen. If I >use a separate thread to do the actual save, the event thread will still >run and I may get other user events before the save is completed. The >problem is that these other user events may change the document while it >is being saved. > >I could disable all commands until the save is done but this seems like a >heavy handed solution to solve a deficiency in JProgressBar. I also tried >using paintImmediately() after setting the progress bar's value. This >works, but the bar flickers like double buffering isn't happening with >paintImmediately.
Unfortunately, disabling changes to the document during a save is the standard approach. The most straightforward approach is to change the cursor to a wait indicator (e.g. hourglass) and prevent any input. I prevent input by putting up a modal dialog that can't be dismissed until the save is done; there might be a better way. In any case, locking up the interface this way is not the best solution usability-wise, but it at least has the benefit of being the "standard" approach, and also being relatively gentle with the system resources. A really spiffy solution would allow the user to start the save operation, and then keep working on the document as if the save were instantaneous; meanwhile, the application is keeping track of changes made to the document after the save was started, displaying them as if the document has in fact changed, even though it's still in the save process. The changes are then "baked in" after the save is finished. If you had sufficient hardware, you could implement this by duplicating the document in memory (assuming that's simultaneous), then save the dupe while allowing changes to the original. A less memory-hogging but more complex approach would keep changes in a list in memory. _______________________________________________ Advanced-swing mailing list [EMAIL PROTECTED] http://eos.dk/mailman/listinfo/advanced-swing
