|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
adapter.fill and progress barWhen I initialize my app, I put up a "splash" screen with a progress bar
while the app fills its datasets. The fill takes longer sometimes than it does other times. Is there anyway to measure/determine the progress of the fill operation? I wish to know this so that I can adjust the progress bar to be more realistic. (Currently, the time to fill the datasets can range from 5 seconds to 20 seconds, even though the dataset size dows not vary very much.) TIA The issue with a progressbar is - you need to know the max, before reading
the first row. And to find the count you need to first execute a select count - which is not terribly cheap (but not as awful as executing a select *). (Please see - http://codebetter.com/blogs/sahil.malik/archive/2005/12/12/135586.aspx ). Maybe a better idea is to just show a rowcount as an indication of progress - but if you must show a progress bar - well yeah you can, but you will need to execute two queries - Regards actually showing it, you can do it using DataAdapter by tapping on the RowChanging and RowChanged events of the DataTable. Alternatively you can use a DataReader to show a progressbar as shown here - http://codebetter.com/blogs/sahil.malik/archive/2005/08/15/130763.aspx - Sahil Malik [MVP] ADO.NET 2.0 book - http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx __________________________________________________________ Show quote "Rain County" <raincounty-at-hotmail> wrote in message news:uF%23kHhYFGHA.1312@TK2MSFTNGP09.phx.gbl... > When I initialize my app, I put up a "splash" screen with a progress bar > while the app fills its datasets. The fill takes longer sometimes than it > does other times. Is there anyway to measure/determine the progress of > the fill operation? I wish to know this so that I can adjust the progress > bar to be more realistic. > > (Currently, the time to fill the datasets can range from 5 seconds to 20 > seconds, even though the dataset size dows not vary very much.) > > TIA > Thank you very much Sahil,
If the RowChanged event will be triggered during the Fill operation, then that is just the hint I needed. Using Select Count (*) rather than Select * was also a good tip. I will be using MSAccess rather than SQL and the table is not humongous, so it should work great. Thanks again. Phil Show quote "Sahil Malik [MVP C#]" <contactmethrumyblog@nospam.com> wrote in message news:usY7lwYFGHA.3900@TK2MSFTNGP10.phx.gbl... > The issue with a progressbar is - you need to know the max, before reading > the first row. And to find the count you need to first execute a select > count - which is not terribly cheap (but not as awful as executing a > select *). (Please see - > http://codebetter.com/blogs/sahil.malik/archive/2005/12/12/135586.aspx ). > Maybe a better idea is to just show a rowcount as an indication of > progress - but if you must show a progress bar - well yeah you can, but > you will need to execute two queries - > > Regards actually showing it, you can do it using DataAdapter by tapping on > the RowChanging and RowChanged events of the DataTable. > > Alternatively you can use a DataReader to show a progressbar as shown > here - > http://codebetter.com/blogs/sahil.malik/archive/2005/08/15/130763.aspx > > - Sahil Malik [MVP] > ADO.NET 2.0 book - > http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx > __________________________________________________________ > > > > "Rain County" <raincounty-at-hotmail> wrote in message > news:uF%23kHhYFGHA.1312@TK2MSFTNGP09.phx.gbl... >> When I initialize my app, I put up a "splash" screen with a progress bar >> while the app fills its datasets. The fill takes longer sometimes than >> it does other times. Is there anyway to measure/determine the progress >> of the fill operation? I wish to know this so that I can adjust the >> progress bar to be more realistic. >> >> (Currently, the time to fill the datasets can range from 5 seconds to 20 >> seconds, even though the dataset size dows not vary very much.) >> >> TIA >> > > Rain,
Here a sample how you can fill a dataset while a dataset is going to be filled, be aware that the total process by this will be longer. http://www.vb-tips.com/default.aspx?ID=49f2cff5-56ad-44fc-a4c6-fc0d5c470f53 I hope this helps, Cor Way better is to use a worker thread for stunts like this - otherwise window
refreshing sucks... -- Show quoteMiha Markic [MVP C#] RightHand .NET consulting & development www.rthand.com Blog: http://cs.rthand.com/blogs/blog_with_righthand/ "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message news:ObmxQPcFGHA.2648@TK2MSFTNGP11.phx.gbl... > Rain, > > Here a sample how you can fill a dataset while a dataset is going to be > filled, be aware that the total process by this will be longer. > > http://www.vb-tips.com/default.aspx?ID=49f2cff5-56ad-44fc-a4c6-fc0d5c470f53 > > I hope this helps, > > Cor > > Miha,
> Way better is to use a worker thread for stunts like this - otherwise Do you mean instead of?> window refreshing sucks... > Can you show me an example, I am curious about that. I could never do it in another way than this because of the fact that opposite to the Update the Fill does not give any event during the fill. An extra problem is that the backgroundworker is not in the UI and the progressbar has to be showed. However let us make it simple, I am really curious for your sample. (Can be in C# no problem) By the way, I will never use this because of all the other overhead. But that I told in my message. Cor No time for sample,
- events raised from backgroundworker (which is not the only way to use worker threads) are synchronized with the control backgroundworker is placed on. Thus you don't need any special synchronization. - perhaps it has some overhead - but the advantage is big: having a responsive UI. The same could be said for windows - why does windows use multithreading? - even with using raw threads, the synchronization with UI is fairly simple You might read Chris Sell's article on this topic: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnforms/html/winforms01232003.asp -- Show quoteMiha Markic [MVP C#] RightHand .NET consulting & development www.rthand.com Blog: http://cs.rthand.com/blogs/blog_with_righthand/ "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message news:uBCwsfcFGHA.1124@TK2MSFTNGP10.phx.gbl... > Miha, > >> Way better is to use a worker thread for stunts like this - otherwise >> window refreshing sucks... >> > Do you mean instead of? > > Can you show me an example, I am curious about that. I could never do it > in another way than this because of the fact that opposite to the Update > the Fill does not give any event during the fill. > > An extra problem is that the backgroundworker is not in the UI and the > progressbar has to be showed. > > However let us make it simple, I am really curious for your sample. (Can > be in C# no problem) > > By the way, I will never use this because of all the other overhead. But > that I told in my message. > > Cor > Miha,
I know this subject, I have had in past (at least more than a year ago) many discussions about this with Jon Skeet, who as it than seems to me, would use multithreading for everything. I have seen that Jon now becomes too in my opinion a little bit more selective for that. Which does not mean that as Jon, I see as well many places where multithreading can be used to give shorter throughput time. However probably can the effort for this be better used in making the proces of getting the data and handling that quicker. Mutlithreading cost forever more processingtime than singlethreading and makes at least a program less maintainable, which is for me a very important factor. Just my opinion. Cor
Show quote
"Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message Tell that to MS - they should have kept the DOS or at worst single threaded news:ec$1X6cFGHA.2040@TK2MSFTNGP14.phx.gbl... > Miha, > > I know this subject, I have had in past (at least more than a year ago) > many discussions about this with Jon Skeet, who as it than seems to me, > would use multithreading for everything. > > I have seen that Jon now becomes too in my opinion a little bit more > selective for that. > > Which does not mean that as Jon, I see as well many places where > multithreading can be used to give shorter throughput time. However > probably can the effort for this be better used in making the proces of > getting the data and handling that quicker. > > Mutlithreading cost forever more processingtime than singlethreading and > makes at least a program less maintainable, which is for me a very > important factor. OS! -- Miha Markic [MVP C#] RightHand .NET consulting & development www.rthand.com Blog: http://cs.rthand.com/blogs/blog_with_righthand/ Miha,
> Tell that to MS - they should have kept the DOS or at worst single Do you mean that you want this.> threaded OS! > I don't agree with you, as I wrote in the message you are replying, there are in my opinion many places where multithreading has a benefit. An OS (or better multitasking/multiprogramming/multiprocessing) is one of those. Cor On Mon, 9 Jan 2006 17:50:50 -0800, "Rain County"
<raincounty-at-hotmail> wrote: >When I initialize my app, I put up a "splash" screen with a progress bar If you're using .NET 2.0 you can use the Progress bar in Marquee mode.>while the app fills its datasets. The fill takes longer sometimes than it >does other times. Is there anyway to measure/determine the progress of the >fill operation? I wish to know this so that I can adjust the progress bar >to be more realistic. > >(Currently, the time to fill the datasets can range from 5 seconds to 20 >seconds, even though the dataset size dows not vary very much.) > >TIA > When you use that mode the bars squares in the bar oscillate from one side to the other while the work is being done. Otis Mukinfus http://www.otismukinfus.com http://www.tomchilders.com Thats a cool idea :)
SM Show quote "Otis Mukinfus" <ph***@emailaddress.com> wrote in message news:mcr8s1lk58167es1u79dd9li6bkuf8spqh@4ax.com... > On Mon, 9 Jan 2006 17:50:50 -0800, "Rain County" > <raincounty-at-hotmail> wrote: > >>When I initialize my app, I put up a "splash" screen with a progress bar >>while the app fills its datasets. The fill takes longer sometimes than it >>does other times. Is there anyway to measure/determine the progress of >>the >>fill operation? I wish to know this so that I can adjust the progress bar >>to be more realistic. >> >>(Currently, the time to fill the datasets can range from 5 seconds to 20 >>seconds, even though the dataset size dows not vary very much.) >> >>TIA >> > > If you're using .NET 2.0 you can use the Progress bar in Marquee mode. > When you use that mode the bars squares in the bar oscillate from one > side to the other while the work is being done. > > > Otis Mukinfus > http://www.otismukinfus.com > http://www.tomchilders.com On Thu, 12 Jan 2006 13:25:57 -0500, "Sahil Malik [MVP C#]"
<contactmethrumyblog@nospam.com> wrote: >Thats a cool idea :) Thanks, Sahil.> >SM [snip] >> If you're using .NET 2.0 you can use the Progress bar in Marquee mode. >> When you use that mode the bars squares in the bar oscillate from one >> side to the other while the work is being done. >> >> >> Otis Mukinfus >> http://www.otismukinfus.com >> http://www.tomchilders.com > It sure solves the problem of needing to know the number of rows returned. My opinion has always been that you don't need to be accurate as to the amount of work left to be done. The important thing is to let the user know the operation is still active. It keeps 'em from clicking stuff to see if they did something wrong or lets them know they're not frozen up. Naturally we should avoid long operations, but sometimes that doesn't work ;o) Otis Mukinfus http://www.otismukinfus.com http://www.tomchilders.com  |
|||||||||||||||||||||||
Other interesting topics