progress bars

[Paul]

i have been working with vb6 for a while but never had the pleasure of using
progress bars. That is until now, one of the programs i have written has
just been modified so that large csv files of 100,000+ lines can be imported
into a database.

the import works fine but the progress bar feature is not working correctly.
The progress bar is set to a max value of the number of records in the csv
file, the records are then imported and the progress bar runs from from zero
to max no problem.

however under the progress bar is a text box that should display the
percentage and update with each import loop but it doesnt update. it stays
blank until the full import is complete then it will show 100%. but if you
step through the program in debug mode the text box updates correctly.

has anyone had any joys with this control. any ideas will be appreciated.
the full import routine is too big to post so i have simplified the progress
bar into a loop if anyone wants to have a look.

Private Sub cmdStart_Click()
While ProgressBar1.Value < ProgressBar1.Max
Do
ProgressBar1.Value = ProgressBar1.Value + 1
txtPercentage.Text = (ProgressBar1.Value / ProgressBar1.Max) * 100 & "%"
Loop
Wend
End Sub

Cheers
Paul

[Stoil Marinov]

Hi Paul,

Comments inline...

--
To reply, take out the .OBVIOUS from the address.

"Paul" <pa**@pgcomputing.net> wrote in message news:1g*****************@news-binary.blueyonder.co.uk...

i have been working with vb6 for a while but never had the pleasure of using
progress bars. That is until now, one of the programs i have written has
just been modified so that large csv files of 100,000+ lines can be imported
into a database.

the import works fine but the progress bar feature is not working correctly.
The progress bar is set to a max value of the number of records in the csv
file, the records are then imported and the progress bar runs from from zero
to max no problem.

however under the progress bar is a text box that should display the
percentage and update with each import loop but it doesnt update. it stays
blank until the full import is complete then it will show 100%. but if you
step through the program in debug mode the text box updates correctly.

has anyone had any joys with this control. any ideas will be appreciated.
the full import routine is too big to post so i have simplified the progress
bar into a loop if anyone wants to have a look.

Private Sub cmdStart_Click()
While ProgressBar1.Value < ProgressBar1.Max
Do
ProgressBar1.Value = ProgressBar1.Value + 1
txtPercentage.Text = (ProgressBar1.Value / ProgressBar1.Max) * 100 & "%"
'Refresh the textbox
txtPercentage.Refresh

Regards,

Stoil
Loop
Wend
End Sub

Cheers
Paul

[Paul]

Thanks for that you are a star, i've spent most of the day looking at this
and i forget something as simple as a refresh. I can finally finish the
program now.

cheers

paul

"Stoil Marinov" <st*******************@firemail.de> wrote in message
news:be************@ID-24932.news.dfncis.de...
Hi Paul,

Comments inline...

--
To reply, take out the .OBVIOUS from the address.

"Paul" <pa**@pgcomputing.net> wrote in message
news:1g*****************@news-binary.blueyonder.co.uk...

i have been working with vb6 for a while but never had the pleasure of using progress bars. That is until now, one of the programs i have written has
just been modified so that large csv files of 100,000+ lines can be imported into a database.

the import works fine but the progress bar feature is not working correctly. The progress bar is set to a max value of the number of records in the csv
file, the records are then imported and the progress bar runs from from zero to max no problem.

however under the progress bar is a text box that should display the
percentage and update with each import loop but it doesnt update. it stays
blank until the full import is complete then it will show 100%. but if you
step through the program in debug mode the text box updates correctly.

has anyone had any joys with this control. any ideas will be appreciated.
the full import routine is too big to post so i have simplified the progress bar into a loop if anyone wants to have a look.

Private Sub cmdStart_Click()
While ProgressBar1.Value < ProgressBar1.Max
Do
ProgressBar1.Value = ProgressBar1.Value + 1
txtPercentage.Text = (ProgressBar1.Value / ProgressBar1.Max) * 100 & "%"

'Refresh the textbox
txtPercentage.Refresh

Regards,

Stoil
Loop
Wend
End Sub

Cheers
Paul

[Captain Proton]

Hi Paul,
Try putting a DoEvents inside your loop. Otherwise VB is so busy with the
import that it doesn't have the time to update the progress bar.
Captain Proton

"Paul" <pa**@pgcomputing.net> schreef in bericht
news:1g*****************@news-binary.blueyonder.co.uk...

i have been working with vb6 for a while but never had the pleasure of using progress bars. That is until now, one of the programs i have written has
just been modified so that large csv files of 100,000+ lines can be imported into a database.

the import works fine but the progress bar feature is not working correctly. The progress bar is set to a max value of the number of records in the csv
file, the records are then imported and the progress bar runs from from zero to max no problem.

however under the progress bar is a text box that should display the
percentage and update with each import loop but it doesnt update. it stays
blank until the full import is complete then it will show 100%. but if you
step through the program in debug mode the text box updates correctly.

has anyone had any joys with this control. any ideas will be appreciated.
the full import routine is too big to post so i have simplified the progress bar into a loop if anyone wants to have a look.

Private Sub cmdStart_Click()
While ProgressBar1.Value < ProgressBar1.Max
Do
ProgressBar1.Value = ProgressBar1.Value + 1
txtPercentage.Text = (ProgressBar1.Value / ProgressBar1.Max) * 100 & "%" Loop
Wend
End Sub

Cheers
Paul

[Duane Bozarth]

Paul wrote:

i have been working with vb6 for a while but never had the pleasure of using
progress bars. That is until now, one of the programs i have written has
just been modified so that large csv files of 100,000+ lines can be imported
into a database.

the import works fine but the progress bar feature is not working correctly.
The progress bar is set to a max value of the number of records in the csv
file, the records are then imported and the progress bar runs from from zero
to max no problem.

Cap'n showed you the .refresh answer to your direct question but I'd
suggest adding some logic to not update <every> pass through the
loop--every couple of percent or so should be often enough and you'll
save a fair amount of display overhead that will speed up the load
process to boot---I'm a pretty rudimentary guy wrt GUIs so I usually do
no more than 10% increments unless that takes so long that there's no
indication of movement--then I'll break it up somewhat finer. I'd much
prefer the machine to be doing something useful, not looking pretty, but
others preferences are the other way 'round, I know... :)

[Stoil Marinov]

Hello,

Comments inline...

--
To reply, take out the .OBVIOUS from the address.

"CajunCoiler (http://www.cajuncoiler.tk)" <ca*********@totallyspamless.cox.net> wrote in message news:YE_Oa.9$N%3.5@lakeread01...

Somewhere between Do, and Loop, add in a DoEvents, and see if that
clears it up for ya. Essentially, the anamole you're experiencing is
due to the loop taking up a padload of CPU time... this leaves little to
no CPU time for the program to update the textbox. The DoEvents
function will relinquish the loop's monopoly long enough for other
things to go on, then resume it's reign over the O/S.

Once, before I was made aware of DoEvents, I had written a program
with a loop in it that took 4-1/2 days to complete. While it ran, nothing
else had been serviced, and by the time it completed, the real-time
clock was 26 hours in arrears. Adding that one function bumped up
the execution time only slightly, but all other processes were being
serviced, and the real-time clock stayed on the mark.
This must have been on a 16 bit Windows.
On 32 bit Windows preemptive multi-tasking is used. Each process is given a slice of the CPU time without regard whether it is in a tight loop or idle. So, DoEvents will not matter in that regard.
On 32 bit Windows DoEvents lets the message loop behind the thread's window process the messages on the message queue.
In this case it is the WM_PAINT message responsible for repainting the Textbox with the new percentage value.
If that is all that is needed, it is better to simply use the Refresh method of the Textbox after setting its value. This has less overhead compared to DoEvents, since only messages regarding the Textbox control are processed. Also it avoids one nasty side effect of DoEvents - reentrance and/or branching to other events code, which, if unaware, could be a real pain.

Regards,

Stoil

"Paul" <pa**@pgcomputing.net> wrote in message
news:1g*****************@news-binary.blueyonder.co.uk...

i have been working with vb6 for a while but never had the pleasure of

using

progress bars. That is until now, one of the programs i have written has
just been modified so that large csv files of 100,000+ lines can be

imported

into a database.

the import works fine but the progress bar feature is not working

correctly.

The progress bar is set to a max value of the number of records in the csv
file, the records are then imported and the progress bar runs from from

zero

to max no problem.

however under the progress bar is a text box that should display the
percentage and update with each import loop but it doesnt update. it stays
blank until the full import is complete then it will show 100%. but if you
step through the program in debug mode the text box updates correctly.

has anyone had any joys with this control. any ideas will be appreciated.
the full import routine is too big to post so i have simplified the

progress

bar into a loop if anyone wants to have a look.

Private Sub cmdStart_Click()
While ProgressBar1.Value < ProgressBar1.Max
Do
ProgressBar1.Value = ProgressBar1.Value + 1
txtPercentage.Text = (ProgressBar1.Value / ProgressBar1.Max) * 100 &

"%"

Loop
Wend
End Sub

Cheers
Paul

[Atreju]

As others have stated, DoEvents statements will make it work better.
However, an alternative is to use a better progressbar control with
other abilities besides the very rudimentary one that comes with VB.

I have made such a control for my own use, but it is not quite perfect
yet. It works fine, but visually it needs some work.

You can get plenty of free progressbar controls that are much more
robust than the included one. Just search on the web for them.

On Wed, 9 Jul 2003 20:43:50 +0100, "Paul" <pa**@pgcomputing.net>
wrote:

i have been working with vb6 for a while but never had the pleasure of using
progress bars. That is until now, one of the programs i have written has
just been modified so that large csv files of 100,000+ lines can be imported
into a database.

the import works fine but the progress bar feature is not working correctly.
The progress bar is set to a max value of the number of records in the csv
file, the records are then imported and the progress bar runs from from zero
to max no problem.

however under the progress bar is a text box that should display the
percentage and update with each import loop but it doesnt update. it stays
blank until the full import is complete then it will show 100%. but if you
step through the program in debug mode the text box updates correctly.

has anyone had any joys with this control. any ideas will be appreciated.
the full import routine is too big to post so i have simplified the progress
bar into a loop if anyone wants to have a look.

Private Sub cmdStart_Click()
While ProgressBar1.Value < ProgressBar1.Max
Do
ProgressBar1.Value = ProgressBar1.Value + 1
txtPercentage.Text = (ProgressBar1.Value / ProgressBar1.Max) * 100 & "%"
Loop
Wend
End Sub

Cheers
Paul

---Atreju---

[eliminate nospam from mail address]

Paul,

Inside of your Do-Loop right after you set txtPercentage.Text try doing
a DoEvents. DoEvents causes VB to pause long enough for the operating
system to process other events (messages). When you change text that is
doing text_change event so that event is pending.

For Example try:

Private Sub cmdStart_Click()
While ProgressBar1.Value < ProgressBar1.Max
Do
ProgressBar1.Value = ProgressBar1.Value + 1
txtPercentage.Text = (ProgressBar1.Value / ProgressBar1.Max) * 100 & "%"
DoEvents
Loop
Wend
End Sub


Paul wrote:

i have been working with vb6 for a while but never had the pleasure of using
progress bars. That is until now, one of the programs i have written has
just been modified so that large csv files of 100,000+ lines can be imported
into a database.

the import works fine but the progress bar feature is not working correctly.
The progress bar is set to a max value of the number of records in the csv
file, the records are then imported and the progress bar runs from from zero
to max no problem.

however under the progress bar is a text box that should display the
percentage and update with each import loop but it doesnt update. it stays
blank until the full import is complete then it will show 100%. but if you
step through the program in debug mode the text box updates correctly.

has anyone had any joys with this control. any ideas will be appreciated.
the full import routine is too big to post so i have simplified the progress
bar into a loop if anyone wants to have a look.

Private Sub cmdStart_Click()
While ProgressBar1.Value < ProgressBar1.Max
Do
ProgressBar1.Value = ProgressBar1.Value + 1
txtPercentage.Text = (ProgressBar1.Value / ProgressBar1.Max) * 100 & "%"
Loop
Wend
End Sub

Cheers
Paul

[CajunCoiler \(http://www.cajuncoiler.tk\)]

You've guessed wrong... it was indeed done in 32-bit.

"CajunCoiler (http://www.cajuncoiler.tk)"
<ca*********@totallyspamless.cox.net> wrote in message
news:YE_Oa.9$N%3.5@lakeread01...

Once, before I was made aware of DoEvents, I had written a program
with a loop in it that took 4-1/2 days to complete. While it ran, nothing
else had been serviced, and by the time it completed, the real-time
clock was 26 hours in arrears. Adding that one function bumped up
the execution time only slightly, but all other processes were being
serviced, and the real-time clock stayed on the mark.

This must have been on a 16 bit Windows.
On 32 bit Windows preemptive multi-tasking is used. Each process is given a
slice of the CPU time without regard whether it is in a tight loop or idle.
So, DoEvents will not matter in that regard.

[Stoil Marinov]

--
To reply, take out the .OBVIOUS from the address.

"CajunCoiler (http://www.cajuncoiler.tk)" <ca*********@totallyspamless.cox.net> wrote in message news:7ffPa.584$N%3.550@lakeread01...

You've guessed wrong... it was indeed done in 32-bit.

"CajunCoiler (http://www.cajuncoiler.tk)"
<ca*********@totallyspamless.cox.net> wrote in message
news:YE_Oa.9$N%3.5@lakeread01...

Once, before I was made aware of DoEvents, I had written a program
with a loop in it that took 4-1/2 days to complete. While it ran, nothing
else had been serviced, and by the time it completed, the real-time ^^^^^^^^^^^^^^^^^^^^^^^
Well, then this statement of yours is wrong.

Regards,

Stoil
clock was 26 hours in arrears. Adding that one function bumped up
the execution time only slightly, but all other processes were being
serviced, and the real-time clock stayed on the mark.

This must have been on a 16 bit Windows.
On 32 bit Windows preemptive multi-tasking is used. Each process is given a
slice of the CPU time without regard whether it is in a tight loop or idle.
So, DoEvents will not matter in that regard.

[CajunCoiler \(http://www.cajuncoiler.tk\)]

Once, before I was made aware of DoEvents, I had written a program
with a loop in it that took 4-1/2 days to complete. While it ran, nothing else had been serviced, and by the time it completed, the real-time

^^^^^^^^^^^^^^^^^^^^^^^ Well, then this statement of yours is wrong.

I don't recall you being here when it happened, so you are in no position
whatsoever to say what did and didn't happen. For this same reason,
you are also in no position to claim whether my statement is right or wrong.

You weren't here, you haven't seen my code. If you claim otherwise, then
you are confessing to monitoring my actions, and my code during development,
and I would have to press charges... which is it going to be?

[Stoil Marinov]

--
To reply, take out the .OBVIOUS from the address.

"CajunCoiler (http://www.cajuncoiler.tk)" <ca*********@totallyspamless.cox.net> wrote in message news:36jPa.1800$N%3.784@lakeread01...

Once, before I was made aware of DoEvents, I had written a program
with a loop in it that took 4-1/2 days to complete. While it ran, nothing else had been serviced, and by the time it completed, the real-time

^^^^^^^^^^^^^^^^^^^^^^^

Well, then this statement of yours is wrong.

I don't recall you being here when it happened, so you are in no position
whatsoever to say what did and didn't happen. For this same reason,
you are also in no position to claim whether my statement is right or wrong.

You weren't here, you haven't seen my code. If you claim otherwise, then
you are confessing to monitoring my actions, and my code during development,
and I would have to press charges... which is it going to be?

Interesting logic <g>.

When a certain physical process is governed by some fundamental principle, one does not need to observe it personally in order to know what the outcome will be.

In this particular case you have two statements that are in contradiction. Either your program was running on a 16 bit Windows, where DoEvents were needed to let other programs get CPU time too. Or, if your program did run on 32 bit Windows, then the effects you describe are simply not possible. Adding DoEvents (or not) in your program, running on 32 bit Windows, which employs preemptive multi-tasking, does not have any effect on the amount of CPU time used by any other running process.
In other words, you cannot prevent other running processes from getting CPU time even if your program was in a tight loop with no DoEvents whatsoever.
You might want to search on google.com on this subject or read some books if you do not believe me.

Regards,

Stoil

[Joe \Nuke Me Xemu\ Foster]

"Stoil Marinov" <st*******************@firemail.de> wrote in message <news:be************@ID-24932.news.uni-berlin.de>...

In this particular case you have two statements that are in contradiction. Either
your program was running on a 16 bit Windows, where DoEvents were needed
to let other programs get CPU time too. Or, if your program did run on 32 bit
Windows, then the effects you describe are simply not possible. Adding
DoEvents (or not) in your program, running on 32 bit Windows, which employs
preemptive multi-tasking, does not have any effect on the amount of CPU time
used by any other running process.
In other words, you cannot prevent other running processes from getting CPU
time even if your program was in a tight loop with no DoEvents whatsoever.
You might want to search on google.com on this subject or read some books
if you do not believe me.

Actually, I have seen some strange behavior in Lose98 that went
away once I added DoEvents to a long-running loop. Internet
Exploiter couldn't open a new window, or something like that.

--
Joe Foster <mailto:jlfoster%40znet.com> Space Cooties! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Frank Adam]

On Thu, 10 Jul 2003 21:11:22 -0700, "Joe \"Nuke Me Xemu\" Foster"
<jo*@bftsi0.UUCP> wrote:

"Stoil Marinov" <st*******************@firemail.de> wrote in message <news:be************@ID-24932.news.uni-berlin.de>...

In this particular case you have two statements that are in contradiction. Either
your program was running on a 16 bit Windows, where DoEvents were needed
to let other programs get CPU time too. Or, if your program did run on 32 bit
Windows, then the effects you describe are simply not possible. Adding
DoEvents (or not) in your program, running on 32 bit Windows, which employs
preemptive multi-tasking, does not have any effect on the amount of CPU time
used by any other running process.
In other words, you cannot prevent other running processes from getting CPU
time even if your program was in a tight loop with no DoEvents whatsoever.
You might want to search on google.com on this subject or read some books
if you do not believe me.

Actually, I have seen some strange behavior in Lose98 that went
away once I added DoEvents to a long-running loop. Internet
Exploiter couldn't open a new window, or something like that.

Yep i remember similar things too, but could you refresh my memory on
which 9x OS was actually 32 bit ? ;-p

--

Regards, Frank

[J French]

On Fri, 11 Jul 2003 05:11:36 GMT, fa**@xxxxoptushome.com.au (Frank
Adam) wrote:

<snip>

Yep i remember similar things too, but could you refresh my memory on
which 9x OS was actually 32 bit ? ;-p

Yes, it is terrifying seen the list of running 16 bit DLLs ....--

Regards, Frank

[Jordan T. Cox]

On Fri, 11 Jul 2003 08:19:09 +0000 (UTC)
Bo*************@iss.u-net.com_.bin (J French) wrote:

On Fri, 11 Jul 2003 05:11:36 GMT, fa**@xxxxoptushome.com.au (Frank
Adam) wrote:

<snip>

Yep i remember similar things too, but could you refresh my memory on
which 9x OS was actually 32 bit ? ;-p

Yes, it is terrifying seen the list of running 16 bit DLLs ....

--

Regards, Frank

I must say that I agree fully with the original poster in this sub-thread. DoEvents has cleared up (unexplainably) a few problems with some our code in the past. Windows is strange indeed.

--
Regards, Jordan Timothy Cox
Programmer & IT Administrator,
Geronimo Development Corporation (http://casefinder.com)

[J French]

On Sun, 20 Jul 2003 14:56:47 -0500, "Jordan T. Cox"
<jc**@casefinder.com> wrote:

On Fri, 11 Jul 2003 08:19:09 +0000 (UTC)
Bo*************@iss.u-net.com_.bin (J French) wrote:

On Fri, 11 Jul 2003 05:11:36 GMT, fa**@xxxxoptushome.com.au (Frank
Adam) wrote:

<snip>

>>
>Yep i remember similar things too, but could you refresh my memory on
>which 9x OS was actually 32 bit ? ;-p
> Yes, it is terrifying seen the list of running 16 bit DLLs ....

>--
>
>Regards, Frank

I must say that I agree fully with the original poster in this sub-thread.
DoEvents has cleared up (unexplainably) a few
problems with some our code in the past. Windows is strange indeed.

Yes, they can often be due to cascading events

One tip I have found useful is to allow multiple calls to set things
up, and set off a Timer, so that one only 'continues' when things have
settled down.
In some ways an alternative to DoEvents
- although in this case Label1.Refresh is the obvious answer