![]() |
![]() | ![]() | ![]() | ![]() | ![]() | ![]() | ![]() |
|
Welcome to Vista Forums we are your forum to discuss Windows Vista x64 and x86 systems. Whether you need help or just want to post an idea you have on Vista, this is the forum for you.
br> br> |
| |||||||
![]() |
| | Thread Tools | Display Modes |
| | #1 (permalink) |
| Guest | 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 |
My System Specs![]() |
| | #2 (permalink) |
| Guest | Re: ProgressBar Newbie question 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 > |
My System Specs![]() |
| | #3 (permalink) |
| Guest | Re: ProgressBar Newbie question 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 >> > |
My System Specs![]() |
| | #4 (permalink) |
| Guest | Re: ProgressBar Newbie question 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 |
My System Specs![]() |
| | #5 (permalink) |
| Guest | Re: ProgressBar Newbie question > > 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 ? |
My System Specs![]() |
| | #6 (permalink) |
| Guest | Re: ProgressBar Newbie question 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 |
My System Specs![]() |
| | #7 (permalink) |
| Guest | Re: ProgressBar Newbie question 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 > > |
My System Specs![]() |
| | #8 (permalink) |
| Guest | Re: ProgressBar Newbie question 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 |
My System Specs![]() |
| | #9 (permalink) |
| Guest | Re: ProgressBar Newbie question 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 > > |
My System Specs![]() |
![]() |
| Thread Tools | |
| Display Modes | |
| |
Similar Threads | ||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Newbie question | RickyTheFish | Virtual PC | 1 | 08-08-2008 03:10 AM |
| Newbie Question #3 | Bare Foot Kid | General Discussion | 16 | 05-13-2008 07:39 PM |
| Newbie Question | Bare Foot Kid | General Discussion | 6 | 04-20-2008 03:58 PM |
| Newbie question | JasonJFT | PowerShell | 6 | 09-09-2007 04:40 PM |
| RE: Newbie Question | cccstar | PowerShell | 0 | 12-18-2006 02:31 PM |