Prev: Working with SQL Server CE under vista (UAC)
Next: The Entity Framework and class libraries
From: JAM on 26 Feb 2010 22:51
I'm using ProgressBar to measure some action from 0% to 100%. But
there are cases when there is no action at all to be taken so I want
the bar to move from 0 to 100 at once. But when I put:

progressbar.Value=100;

the bar does not jump immediately to the end. It goes there in about
one second animation like it is doing something. It's not a big deal,
but it kind of seems misleading. Is there a way to disable this ?

JAM
From: Harlan Messinger on 26 Feb 2010 23:41
JAM wrote:
> I'm using ProgressBar to measure some action from 0% to 100%. But
> there are cases when there is no action at all to be taken so I want
> the bar to move from 0 to 100 at once. But when I put:
>
> progressbar.Value=100;
>
> the bar does not jump immediately to the end. It goes there in about
> one second animation like it is doing something. It's not a big deal,
> but it kind of seems misleading. Is there a way to disable this ?
>

I think the main point of the Continuous style is that instead of having
bar jerk from one milestone to the next (for example, if you set it
first at 0, then at 12, then at 15, then at 38, then at 70, then at 92,
and finally at 100), it transitions smoothly. Likewise for jumping
directly from 0 to 100. I don't believe your users will be misled by
this, since they have no idea that the code behind the scenes just set
the bar's Value directly to 100 and don't share your expectation that it
should register as an instantaneous shift in the bar's appearance. If
they think anything about it at all, I suspect it will be more along the
lines of, "Wow, that was quick."
From: Peter Duniho on 27 Feb 2010 00:23
JAM wrote:
> I'm using ProgressBar to measure some action from 0% to 100%. But
> there are cases when there is no action at all to be taken so I want
> the bar to move from 0 to 100 at once. But when I put:
>
> progressbar.Value=100;
>
> the bar does not jump immediately to the end. It goes there in about
> one second animation like it is doing something. It's not a big deal,
> but it kind of seems misleading. Is there a way to disable this ?

I've never noticed an undue delay having the progress bar go from 0 to
100 in one shot. Seems fine to me.

But, you may find that if you simply detect the "no action" case and
simply initialize the progress bar to 100% before it's displayed, that
does what you want.

Of course, there is the question of why you're showing a progress bar at
all if there's nothing to do. :)

Pete
From: JAM on 27 Feb 2010 11:28
On Feb 27, 12:23 am, Peter Duniho <no.peted.s...(a)no.nwlink.spam.com>
wrote:
> JAM wrote:

> I've never noticed an undue delay having the progress bar go from 0 to
> 100 in one shot.  Seems fine to me.

You might not represent 95 precentile :-)

> But, you may find that if you simply detect the "no action" case and
> simply initialize the progress bar to 100% before it's displayed, that
> does what you want.

Thank you for nothing. You haven't answered a question. I don't know
that up-front. It is very costly to find out if action is needed or
not. In fact I'm using Backgroundworker to find it and then to
continue with action so my interface remains responsive. But the
action count is the outcome of long calculations that take significant
fraction of a second. I don't want to hide the progress bar for half a
second only to show it fully green half a second later. This will be
horrible, flickering.

> Of course, there is the question of why you're showing a progress bar at
> all if there's nothing to do.  :)

Because it is aesthetic to show it always. Do you want to discuss
aesthetics of my form or answer simple question if it is possible to
speed up the bar ? :-)

>
> Pete

JAM
From: JAM on 27 Feb 2010 11:39
On Feb 26, 11:41 pm, Harlan Messinger
<hm.usenetremovert...(a)gavelcade.com> wrote:
>
> I think the main point of the Continuous style is that instead of having
> bar jerk from one milestone to the next (for example, if you set it
> first at 0, then at 12, then at 15, then at 38, then at 70, then at 92,
> and finally at 100), it transitions smoothly.

I would rather prefer it to be a choice, but it seems that you are
telling me that it is impossible to go around this feature easily :-(
In fact the animation is actually quite poor. It is far from smooth,
looks rather jerky on long progress bars. When it goes from 0 to 100
(max) it does it in several jerky semi smooth jumps. If you do a lot
of actions that take time and which are tracked by progress bar,
everything looks smooth, but if the action is fast or there is no
action at all, the progress is far from smooth. Maybe it is video card
dependent ? I have NVidia 8800 GT which on paper should be quite
powerful. Anyway, the jerkinees of this progress is the main reason
that I don't like it and I would prefer to jump to 100% at once. It
will actually look better than the default Microsoft implementation.

> Likewise for jumping
> directly from 0 to 100. I don't believe your users will be misled by
> this, since they have no idea that the code behind the scenes just set
> the bar's Value directly to 100 and don't share your expectation that it
> should register as an instantaneous shift in the bar's appearance. If
> they think anything about it at all, I suspect it will be more along the
> lines of, "Wow, that was quick."

I must be one of those not impressed. The Microsoft SyncToy has the
same effect. When it finds that there is nothing to sync it does not
jumps to 100 at once, but actually goes there in several jerky steps.
I find it not not very pleasing and misleading that it is actually
doing some fast sync where in fact it does nothing. One can see that
it did nothing above the progress bar later in synchronization
summary.

JAM
 |  Next  |  Last
Pages: 1 2
Prev: Working with SQL Server CE under vista (UAC)
Next: The Entity Framework and class libraries