ProgressBar Newbie question

Hi everybody,

I'm trying to basically use a progressbar on my UI.
I dosen't work as I expected as the progressbar doesn't refresh while
my process is running but only when it finishes.
I road (in this post
http://groups.google.fr/group/micros...85317f465db3f3)
that I have to update my progressbar in a different thread.

This post is quiet old and I can't believe that (even if I understand
it technically). Do I really have to create a thread just to make the
pregressebar control usefull, really ???

Thanx in advance

In general, if you have a long running task on the UI thread, and you wish
to have a responsive UI you will need to restructure your task.

See this section in the documentation for details:
http://windowssdk.msdn.microsoft.com...70(VS.80).aspx

There are a few samples there. The "A Single Threaded Application with a
Long Running Calculation" sample demonstrates how to avoid using a seperate
thread by breaking a long running task up into more managable chunks and
running those in the idle time of the UI thread.

- Doug

"Pon" <pongla.public@laposte.net> wrote in message
news:1161512533.312762.5430@i3g2000cwc.googlegroups.com...
> Hi everybody,
>
> I'm trying to basically use a progressbar on my UI.
> I dosen't work as I expected as the progressbar doesn't refresh while
> my process is running but only when it finishes.
> I road (in this post
> http://groups.google.fr/group/micros...85317f465db3f3)
> that I have to update my progressbar in a different thread.
>
> This post is quiet old and I can't believe that (even if I understand
> it technically). Do I really have to create a thread just to make the
> pregressebar control usefull, really ???
>
> Thanx in advance
>

Thanx a lot for the answer. I gonna have a look (for now unfortunately, i
can't find the "Single Threaded Application With Long Running Calculation
Sample" in my SDK WPF sample directory, even in the last version of the SDK
i've just downloaded... is it not supposed to be found there ?).
Just a first comment anyhow. It seems everything it's done to keep the UI
responsive as if it was the "standart" requirement. But IMHO, in mots cases,
at least very often (at least in MY case : ) ), we just want our UI not to
response ! We don't want it to freeze (i mean not refresh) but we don't want
the user to be able to run another task either. Precisely because we don't
do a multitask application and/or because the result of the long running
calculation is crucial.
My impression is taht it's just a way to make things more difficult witouht
any good reason. But I'm probably missing something.

Patrice


"Douglas Stockwell" <doug@remove.11011.net> a écrit dans le message de news:
FA76C881-0D3D-45BD-A7F6-B99610ED638F@microsoft.com...
> In general, if you have a long running task on the UI thread, and you wish
> to have a responsive UI you will need to restructure your task.
>
> See this section in the documentation for details:
> http://windowssdk.msdn.microsoft.com...70(VS.80).aspx
>
> There are a few samples there. The "A Single Threaded Application with a
> Long Running Calculation" sample demonstrates how to avoid using a
> seperate thread by breaking a long running task up into more managable
> chunks and running those in the idle time of the UI thread.
>
> - Doug
>
> "Pon" <pongla.public@laposte.net> wrote in message
> news:1161512533.312762.5430@i3g2000cwc.googlegroups.com...
>> Hi everybody,
>>
>> I'm trying to basically use a progressbar on my UI.
>> I dosen't work as I expected as the progressbar doesn't refresh while
>> my process is running but only when it finishes.
>> I road (in this post
>> http://groups.google.fr/group/micros...85317f465db3f3)
>> that I have to update my progressbar in a different thread.
>>
>> This post is quiet old and I can't believe that (even if I understand
>> it technically). Do I really have to create a thread just to make the
>> pregressebar control usefull, really ???
>>
>> Thanx in advance
>>
>

Hello Pon,

> Thanx a lot for the answer. I gonna have a look (for now
> unfortunately, i
> can't find the "Single Threaded Application With Long Running
> Calculation
> Sample" in my SDK WPF sample directory, even in the last version of
> the SDK
> i've just downloaded... is it not supposed to be found there ?).
> Just a first comment anyhow. It seems everything it's done to keep the
> UI
> responsive as if it was the "standart" requirement. But IMHO, in mots
> cases,
> at least very often (at least in MY case : ) ), we just want our UI
> not to
> response ! We don't want it to freeze (i mean not refresh) but we
> don't want
> the user to be able to run another task either. Precisely because we
> don't
> do a multitask application and/or because the result of the long
> running
> calculation is crucial.
> My impression is taht it's just a way to make things more difficult
> witouht
> any good reason. But I'm probably missing something.
> Patrice
>
> "Douglas Stockwell" <doug@remove.11011.net> a écrit dans le message de
> news: FA76C881-0D3D-45BD-A7F6-B99610ED638F@microsoft.com...
>
>> In general, if you have a long running task on the UI thread, and you
>> wish to have a responsive UI you will need to restructure your task.
>>
>> See this section in the documentation for details:
>> http://windowssdk.msdn.microsoft.com...1870(VS.80).as
>> px
>>
>> There are a few samples there. The "A Single Threaded Application
>> with a Long Running Calculation" sample demonstrates how to avoid
>> using a seperate thread by breaking a long running task up into more
>> managable chunks and running those in the idle time of the UI thread.
>>
>> - Doug
>>
>> "Pon" <pongla.public@laposte.net> wrote in message
>> news:1161512533.312762.5430@i3g2000cwc.googlegroups.com...
>>
>>> Hi everybody,
>>>
>>> I'm trying to basically use a progressbar on my UI.
>>>
>>> I dosen't work as I expected as the progressbar doesn't refresh
>>> while
>>>
>>> my process is running but only when it finishes.
>>>
>>> I road (in this post
>>>
>>> http://groups.google.fr/group/micros....developer.win
>>> fx.avalon/browse_frm/thread/4e566519f2f0e68/d585317f465db3f3?lnk=gst
>>> &q=progressbar&rnum=1#d585317f465db3f3)
>>>
>>> that I have to update my progressbar in a different thread.
>>>
>>> This post is quiet old and I can't believe that (even if I
>>> understand it technically). Do I really have to create a thread just
>>> to make the pregressebar control usefull, really ???
>>>
>>> Thanx in advance
>>>

The online version is located here:

http://windowssdk.msdn.microsoft.com...70(VS.80).aspx

You can also get away with using BackgroundWorker with WPF too. This has
a good API for working with progress bars.

http://blogs.msdn.com/jfoscoding/arc...30/487043.aspx

-Paul

>
> The online version is located here:
>
> http://windowssdk.msdn.microsoft.com...70(VS.80).aspx

Yeah I've found it. Thank you anyhow.

> You can also get away with using BackgroundWorker with WPF too. This has a
> good API for working with progress bars.
>
> http://blogs.msdn.com/jfoscoding/arc...30/487043.aspx

Thanx for this suggestion. It seems to be interresting. But does it work
with WPF forms ? I'm wondering cause on the linked page, I can read :

"If you are not familiar with the BackgroundWorker, it is a newly released
component within Windows Forms 2.0 which adds safe, easy, multithreading
capabilities to your application."

And it seems to deal with doevents method thats as far as i know is specific
to windows form. Am I wrong ?

Hello Pon,

>> The online version is located here:
>>
>> http://windowssdk.msdn.microsoft.com...1870(VS.80).as
>> px
>>
> Yeah I've found it. Thank you anyhow.
>
>> You can also get away with using BackgroundWorker with WPF too. This
>> has a good API for working with progress bars.
>>
>> http://blogs.msdn.com/jfoscoding/arc...30/487043.aspx
>>
> Thanx for this suggestion. It seems to be interresting. But does it
> work with WPF forms ? I'm wondering cause on the linked page, I can
> read :
>
> "If you are not familiar with the BackgroundWorker, it is a newly
> released component within Windows Forms 2.0 which adds safe, easy,
> multithreading capabilities to your application."
>
> And it seems to deal with doevents method thats as far as i know is
> specific to windows form. Am I wrong ?
>

I use it on my WPF forms just fine. Just reference System.ComponentModel.

-Paul

Alleluhia ! After the headhache, I was close to the nervous breakdown with
all these thread stuff.
And I saw the light thanx to the Backgroundworker thats works (background)
perfectly !
There's no doubt that's the easiest way to achieve what I wanted.

Thanx a lot Paul.

But after this enthousisasm, i'm a little bit perplexed. I don't want to
philosophize, but am I really the only one guy to find it surprising (and
not normal) to have to deal with threading concerns just to make a
progressbar usefull ?
Does anyone know why is so tricky in WPF (at least when u think you just
have to write mypgb.value = x) ?

>> And it seems to deal with doevents method thats as far as i know is
>> specific to windows form. Am I wrong ?
>>
>
> I use it on my WPF forms just fine. Just reference System.ComponentModel.
>
> -Paul
>
>

Hello Pon,

> Alleluhia ! After the headhache, I was close to the nervous breakdown
> with
> all these thread stuff.
> And I saw the light thanx to the Backgroundworker thats works
> (background)
> perfectly !
> There's no doubt that's the easiest way to achieve what I wanted.
> Thanx a lot Paul.
>
> But after this enthousisasm, i'm a little bit perplexed. I don't want
> to
> philosophize, but am I really the only one guy to find it surprising
> (and
> not normal) to have to deal with threading concerns just to make a
> progressbar usefull ?
> Does anyone know why is so tricky in WPF (at least when u think you
> just
> have to write mypgb.value = x) ?
>>> And it seems to deal with doevents method thats as far as i know is
>>> specific to windows form. Am I wrong ?
>>>
>> I use it on my WPF forms just fine. Just reference
>> System.ComponentModel.
>>
>> -Paul
>>

It basically boils down to doing any long term task on the UI thread. "Most"
everything runs on the UI thread so the UI won't update until your task is
done. The progress bar is a prime example. You can keep progressing it but
WPF won't update it until its unblocked by your task and by that time your
task is done so the bar shows 100%. There have been many discussions about
threading on the forums. Here is one for an example:

http://forums.microsoft.com/MSDN/Sho...02081&SiteID=1

-Paul

Thanx again Paul. I rode the post and it confirmed me that there is no real
deep reason (but I may miss something) that makes impossible to provide an
"update" or "refresh" method to enforce UI to repaint. WPF is really really
great (i can't even think to go back to winform any more) but this kind of
annoying things could discourage many common developpers.
I finally spent an entire day to use a poor progressbar. That's much... too
much don't u think ?
Maybe with the next release....



"Paul Czywczynski" <paul(at)@cbico(dot).com> a écrit dans le message de
news: 594f83ff3e1fb48c8c4d61cc3e2da@news.microsoft.com...
> Hello Pon,
>
>> Alleluhia ! After the headhache, I was close to the nervous breakdown
>> with
>> all these thread stuff.
>> And I saw the light thanx to the Backgroundworker thats works
>> (background)
>> perfectly !
>> There's no doubt that's the easiest way to achieve what I wanted.
>> Thanx a lot Paul.
>>
>> But after this enthousisasm, i'm a little bit perplexed. I don't want
>> to
>> philosophize, but am I really the only one guy to find it surprising
>> (and
>> not normal) to have to deal with threading concerns just to make a
>> progressbar usefull ?
>> Does anyone know why is so tricky in WPF (at least when u think you
>> just
>> have to write mypgb.value = x) ?
>>>> And it seems to deal with doevents method thats as far as i know is
>>>> specific to windows form. Am I wrong ?
>>>>
>>> I use it on my WPF forms just fine. Just reference
>>> System.ComponentModel.
>>>
>>> -Paul
>>>
>
> It basically boils down to doing any long term task on the UI thread.
> "Most" everything runs on the UI thread so the UI won't update until your
> task is done. The progress bar is a prime example. You can keep
> progressing it but WPF won't update it until its unblocked by your task
> and by that time your task is done so the bar shows 100%. There have been
> many discussions about threading on the forums. Here is one for an
> example:
>
> http://forums.microsoft.com/MSDN/Sho...02081&SiteID=1
>
> -Paul
>
>