On Sun, 17 Feb 2008 11:16:15 -0800, K Viltersten <tm**@viltersten.com
wrote:
I noticed that there's a property for the bar stating what time
it should take for the animation to move the fill to the requested spot.
What property are you referring to? If you're talking about the
ProgressBar.MarqueeAnimationSpeed property, I believe that applies only to
the marquee-style progress bar. That is, the one that just has the blocks
animating across the bar over and over, rather than reflecting actual
progress.
I'm guessing that's the time i should delay
my text updating by. Correct?
I don't think that property would be useful in this case at all. But you
could try it and see. I would try setting it to 0; if it has any effect
on a non-marquee progress bar, maybe that would make the animation go away
entirely.
But again, from the docs anyway, it doesn't look like that'd actually have
any effect for a non-marquee progress bar.
When you mentioned a delay - is there an other way to do
it than threads? I've found this solution.
else {
System.Threading.Thread.Sleep (1000);
status.Text = "Done."; }
The thing is that while it postpones the text update (good, good) it
also removes the animation of the bar. By other
words - the bar waits for a second, then skips to the new
position, instead of being "pumped-up".
Instead of blocking your thread with the Sleep() method, you could
(should, IMHO) instead use a timer or background thread. For example:
System.Windows.Forms.Timer timer = new System.Windows.Forms.Timer();
timer.Interval = 1000;
timer.Tick += delegate(object sender, EventArgs e) { status.Text =
"Done"; timer.Stop(); };
timer.Start();
Or:
BackgroundWorker bw = new BackgroundWorker();
bw.DoWork += delegate(object sender, DoWorkEventArgs e)
{ Thread.Sleep(1000); };
bw.RunWorkerCompleted += delegate(object sender,
RunWorkerCompletedEventArgs e) { status.Text = "Done"; }
bw.RunWorkerAsync();
I don't really recommend the latter, as I think it's not a great idea to
block arbitrarily in thread pool threads (and should be avoided in any
thread, for that matter). I also think the latter isn't quite as nice
just in terms of how it's put together.
But with the delay only being 1 second, it's probably not that big of a
problem if you really really wanted to.
I'd use the Timer solution though.
Either of the solutions would allow the text to not be updated until
later, while still allowing the progress bar to do the animation it wants
to do.
Most of all, it would be nice to get a report from the bar saying "yey,
i'm done animating" and then proceede.
Too much?
No, not too much. I think that given that the bar animates, it would be
nice to either have control over the animation, or to be able to receive
updates regarding the status of the animation.
But as far as I know, neither of those are options. So if you really
don't want the text updated until the progress bar has had a chance to
visually reach the end, you're stuck with hacks such as the above. If
you're going to do a hack though, at least try to make it as friendly as
possible. Blocking the GUI thread for a full second isn't very friendly..
Pete
