On Dec 23, 2004, at 10:55 AM, John St. Ledger wrote:
it seems to me that Sun's ProgressMonitor is a somewhat weak
implementation of a decent idea. why is it so hard to get a PM to do
--
well, to do almost anything at all?
The ProgressMonitor works just fine, if you implement it properly. Sun
has a tutorial on their web site on how to use the ProgressMonitor,
and most Swing books have an explanation. The correct set up wasn't
obvious to me after reading the books or the tutorial.
Werner's suggestions solved my problem. With hindsight, I can describe
my problem as having trouble getting the PM to pop up fast enough.
Indeed, I set it to come up after two milliseconds, so why (I wondered)
did it take five or ten seconds to actually appear? I still don't have
the answer, but Werner's tip to set the pop-up-time to zero
milliseconds worked, and the PM now appears right as my thread is
spawned, as I wanted.
It sounds like you understand the thread issue, so I can't tell what
you did wrong. To get my application to work, I copied the
SwingWorker class from the tutorial, and modified it for my classes.
SwingWorker is not part of the API. Here is some of my code. Maybe
it will help.
Yes, I do understand the thread issue (in fact, long ago I posted a
question to which your thread explanation was the answer -- why
wouldn't my PM pop up when the algorithm was executed on the EDT?) but
thank you for the SwingWorker tip.
ps all these problems are after i worked around the serious bug in
Apple's ProgressBarUI implementation which results in a terrible
memory
leak, by telling swing not to use Apple's UI plaf class.
I haven't used a ProgressMonitor in a couple of years. Could you
describe this problem in more detail and your work around, and any
issues with the work around?
Yeah. There's an old thread about this, but here's the jist: Apple's
AquaProgressBarUI has a serious (and, as I understand it, longstanding)
bug which causes a kind of memory/processor leak. To animate the
JProgressBar, Apple spawns a thread to send bar-image-update events,
but after the JProgressBar is no longer visible, that thread stays in
memory and continues to send out events. The thread stays active until
the application exits, so if an application has ProgressMonitors pop up
from time to time (as mine does) each one will leave a thread in the
background churning out these events. (And an application which shows
any JProgressBar, but my application only uses them in PMs.) One
partial solution I figured out was to throttle down the animation speed
(the default was something like 200 updates per second, and I throttled
it down to five or ten). But my eventual solution was to simply not use
AquaProgressBarUI; instead I use BasicParogressBarUI, which is ugly but
at least it doesn't cause my application to atrophy and eventually chew
up all available memory.
The man who maintains Quaqua (a package which fixes a number of
Swing-on-Mac issues) was interested in a reimplemented progress bar UI,
but I never wrote one and apparently neither did anyone else.
I hope that explanation can save someone else the same headache I went
through.
peace; and thanks again to Werner,
nicholas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
