progress bars

Re: progress bars

Hi Paul,

Comments inline...

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



"Paul" <paul@pgcomputi ng.net> wrote in message news:1g_Oa.2746 [email protected] er.co.uk...[color=blue]
> 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.Va lue < ProgressBar1.Ma x
> Do
> ProgressBar1.Va lue = ProgressBar1.Va lue + 1
> txtPercentage.T ext = (ProgressBar1.V alue / ProgressBar1.Ma x) * 100 & "%"[/color]

'Refresh the textbox
txtPercentage.R efresh

Regards,

Stoil
[color=blue]
> Loop
> Wend
> End Sub
>
> Cheers
> Paul
>
>
> [/color]

Re: progress bars

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" <stoil.marinov. OBVIOUS@firemai l.de> wrote in message
news:behrug$5b8 [email protected] is.de...
Hi Paul,

Comments inline...

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



"Paul" <paul@pgcomputi ng.net> wrote in message
news:1g_Oa.2746 [email protected] er.co.uk...[color=blue]
> i have been working with vb6 for a while but never had the pleasure of[/color]
using[color=blue]
> 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[/color]
imported[color=blue]
> into a database.
>
> the import works fine but the progress bar feature is not working[/color]
correctly.[color=blue]
> 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[/color]
zero[color=blue]
> 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[/color]
progress[color=blue]
> bar into a loop if anyone wants to have a look.
>
> Private Sub cmdStart_Click( )
> While ProgressBar1.Va lue < ProgressBar1.Ma x
> Do
> ProgressBar1.Va lue = ProgressBar1.Va lue + 1
> txtPercentage.T ext = (ProgressBar1.V alue / ProgressBar1.Ma x) * 100 &[/color]
"%"

'Refresh the textbox
txtPercentage.R efresh

Regards,

Stoil
[color=blue]
> Loop
> Wend
> End Sub
>
> Cheers
> Paul
>
>
>[/color]

Re: progress bars

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" <paul@pgcomputi ng.net> schreef in bericht
news:1g_Oa.2746 [email protected] er.co.uk...[color=blue]
> i have been working with vb6 for a while but never had the pleasure of[/color]
using[color=blue]
> 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[/color]
imported[color=blue]
> into a database.
>
> the import works fine but the progress bar feature is not working[/color]
correctly.[color=blue]
> 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[/color]
zero[color=blue]
> 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[/color]
progress[color=blue]
> bar into a loop if anyone wants to have a look.
>
> Private Sub cmdStart_Click( )
> While ProgressBar1.Va lue < ProgressBar1.Ma x
> Do
> ProgressBar1.Va lue = ProgressBar1.Va lue + 1
> txtPercentage.T ext = (ProgressBar1.V alue / ProgressBar1.Ma x) * 100 &[/color]
"%"[color=blue]
> Loop
> Wend
> End Sub
>
> Cheers
> Paul[/color]

Re: progress bars

Paul wrote:[color=blue]
>
> 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.[/color]

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... :)

Re: progress bars

Hello,

Comments inline...

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



"CajunCoile r (http://www.cajuncoiler .tk)" <cajuncoiler@to tallyspamless.c ox.net> wrote in message news:YE_Oa.9$N% 3.5@lakeread01. ..[color=blue]
> 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.[/color]

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
[color=blue]
>
> "Paul" <paul@pgcomputi ng.net> wrote in message
> news:1g_Oa.2746 [email protected] er.co.uk...[color=green]
> > i have been working with vb6 for a while but never had the pleasure of[/color]
> using[color=green]
> > 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[/color]
> imported[color=green]
> > into a database.
> >
> > the import works fine but the progress bar feature is not working[/color]
> correctly.[color=green]
> > 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[/color]
> zero[color=green]
> > 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[/color]
> progress[color=green]
> > bar into a loop if anyone wants to have a look.
> >
> > Private Sub cmdStart_Click( )
> > While ProgressBar1.Va lue < ProgressBar1.Ma x
> > Do
> > ProgressBar1.Va lue = ProgressBar1.Va lue + 1
> > txtPercentage.T ext = (ProgressBar1.V alue / ProgressBar1.Ma x) * 100 &[/color]
> "%"[color=green]
> > Loop
> > Wend
> > End Sub
> >
> > Cheers
> > Paul
> >
> >
> >[/color]
>
> [/color]

Re: progress bars

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" <paul@pgcomputi ng.net>
wrote:
[color=blue]
>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.Va lue < ProgressBar1.Ma x
> Do
> ProgressBar1.Va lue = ProgressBar1.Va lue + 1
> txtPercentage.T ext = (ProgressBar1.V alue / ProgressBar1.Ma x) * 100 & "%"
> Loop
> Wend
>End Sub
>
>Cheers
>Paul
>
>[/color]



---Atreju---

Re: progress bars

Paul,

Inside of your Do-Loop right after you set txtPercentage.T ext 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.Va lue < ProgressBar1.Ma x
Do
ProgressBar1.Va lue = ProgressBar1.Va lue + 1
txtPercentage.T ext = (ProgressBar1.V alue / ProgressBar1.Ma x) * 100 & "%"
DoEvents
Loop
Wend
End Sub




Paul wrote:
[color=blue]
>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.Va lue < ProgressBar1.Ma x
> Do
> ProgressBar1.Va lue = ProgressBar1.Va lue + 1
> txtPercentage.T ext = (ProgressBar1.V alue / ProgressBar1.Ma x) * 100 & "%"
> Loop
> Wend
>End Sub
>
>Cheers
>Paul
>
>
>
>
>[/color]

Re: progress bars


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

"CajunCoile r (http://www.cajuncoiler .tk)"
<cajuncoiler@to tallyspamless.c ox.net> wrote in message
news:YE_Oa.9$N% 3.5@lakeread01. ..[color=blue]
> 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.[/color]

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.

Re: progress bars



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



"CajunCoile r (http://www.cajuncoiler .tk)" <cajuncoiler@to tallyspamless.c ox.net> wrote in message news:7ffPa.584$ N%3.550@lakerea d01...[color=blue]
>
> You've guessed wrong... it was indeed done in 32-bit.
>
> "CajunCoile r (http://www.cajuncoiler .tk)"
> <cajuncoiler@to tallyspamless.c ox.net> wrote in message
> news:YE_Oa.9$N% 3.5@lakeread01. ..[color=green]
> > 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[/color][/color]
^^^^^^^^^^^^^^^ ^^^^^^^^
Well, then this statement of yours is wrong.

Regards,

Stoil
[color=blue][color=green]
> > 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.[/color]
>
> 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.
>
> [/color]

Re: progress bars

[color=blue][color=green]
> > 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,[/color][/color]
nothing[color=blue][color=green]
> > else had been serviced, and by the time it completed, the real-time[/color][/color]
^^^^^^^^^^^^^^^ ^^^^^^^^[color=blue]
> Well, then this statement of yours is wrong.[/color]

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?

Re: progress bars



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



"CajunCoile r (http://www.cajuncoiler .tk)" <cajuncoiler@to tallyspamless.c ox.net> wrote in message news:36jPa.1800 $N%3.784@lakere ad01...[color=blue]
> [color=green][color=darkred]
> > > 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,[/color][/color]
> nothing[color=green][color=darkred]
> > > else had been serviced, and by the time it completed, the real-time[/color][/color]
> ^^^^^^^^^^^^^^^ ^^^^^^^^[color=green]
> > Well, then this statement of yours is wrong.[/color]
>
> 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?[/color]

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
[color=blue]
>
> [/color]

Re: progress bars

"Stoil Marinov" <stoil.marinov. OBVIOUS@firemai l.de> wrote in message <news:bekgj4$5c [email protected]>...
[color=blue]
> 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.[/color]

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:jlfoste r%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!

Re: progress bars

On Thu, 10 Jul 2003 21:11:22 -0700, "Joe \"Nuke Me Xemu\" Foster"
<[email protected] P> wrote:
[color=blue]
>"Stoil Marinov" <stoil.marinov. OBVIOUS@firemai l.de> wrote in message <news:bekgj4$5c [email protected]>...
>[color=green]
>> 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.[/color]
>
>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.
>[/color]
Yep i remember similar things too, but could you refresh my memory on
which 9x OS was actually 32 bit ? ;-p

--

Regards, Frank

Re: progress bars

On Fri, 11 Jul 2003 05:11:36 GMT, fajp@xxxxoptush ome.com.au (Frank
Adam) wrote:

<snip>[color=blue][color=green]
>>[/color]
>Yep i remember similar things too, but could you refresh my memory on
>which 9x OS was actually 32 bit ? ;-p
>[/color]
Yes, it is terrifying seen the list of running 16 bit DLLs ....[color=blue]
>--
>
>Regards, Frank[/color]