Posted by joeabbott on June 12, 2011
OK … I haven’t dug deeply on this problem so it’s pretty wimpy to give a shout out for help, but I’m also not sure I will look into it any further. Color me lazy or realize that this little nut has nothing to do with the problem I want to solve and just something I stumbled up on the way.
Ultimately I want to push the information into a database to serialize into a form another program I have can read. Or maybe I plot them directly into a mapping program. For now, I just want to play around a bit to understand the problem better.
Anyhow, after I read the file I saw the “Progress Bar” control in the toolbox and I thought, “I might ultimately be reading a ton of data, maybe I should drop that in.”
And this was where the problem sprung up.
After digging in the help docs (I’ve never used a progress bar before) I got a program going that would read the data, show the line being read, and have the progress bar zip along. All very nice and easy, but I noticed that the file would be read in its entirety while the progress bar was still incomplete!
It’s a really simple program so I couldn’t see what was going wrong … here’s the code with a picture of the progress bar when the “read” was complete:
//Continue to read until you reach end of file
while (line != null)
//write the line to window
label1.Text = line;
//update the progress bar
//Read the next line
line = sr.ReadLine();
The progressBar1.Update(); line is likely redundant, as the line above it should serve the same purpose … I had added the Update line to see if that would help move the progress beyond the 70% completion point. It didn’t.
I tinkered a bit but didn’t make headway, so I slept on the problem before looking at it again this AM.
In the morning I recalled a recent conversation with a coworker on an unrelated topic but one that involved the computer outpacing some steps while doing others. Now, the above program is very unsophisticated. I have all the work being done on the same thread. As a matter of fact, while it’s reading the file, you can’t interact with the window … it just won’t respond. You can’t move it, can’t kill it … nothing. But, I’m just working out ideas here first; I’ll fix it up when\if I need to.
Anyhow, remembering that conversation, I thought I might put a small sleep in the program … just a tiny thing to let the progress bar “catch up”. By tinkering around, this is what I found on four different runs:
I inserted the Sleep line just after the progressBar1.Update line, but you could put it anywhere in the while loop and you’ll be fine. Oh, and a Sleep(1) will sleep for a millisecond, Sleep(10) waits for a hundredth of a second, and Sleep(100) will put a pause of a tenth of a second between each read. So on a 1400+ line data file using the Sleep(100), I’ve just artificially added about 2 minutes of delay.
But this helped!
You can see that, as I put in longer and longer “waits”, without any other changes to the program, the progress bar would complete more and more. The final image shows the tiniest bit of “undone” still in the progress bar, but this is likely an “off by one” error that I’d introduced when setting up the progress bar control.
So that’s my problem: why do I need to sleep in order for the progress bar to keep up with the program?
I sorta get that I may not using it as intended (reading individual lines from a file is pretty zippy) and that it’s a complex control, but I am curious why it’s not able to keep pace.
Anyhow, that’s as much as I’m going to make of things. I’ll probably pull the progress bar and just leave the “label2” text item (which shows what line is being read). I can figure out the percentage complete on my own.
However, if you have experience with progress bars and know why I need to wait in order for the control to correctly display the current percentage, I’d love to hear about it!
Thanks for reading.