Timer Events stop working

[tony]

Hi,

I have a form where a user can update a lot of data, which once they
have finished will record the changes. Just to let the user know that
something was happening I had a progress meter appear. As the updates
are done through VBA and not running a query I am able to calculate
the number of records to be changed and thus update the progress meter
with 100th increments. I am using the MSComctlLib.ProgCtrl.2 Active X
progress bar 6.0.

This all works fine until the number of records being changed gets to
around 500 at which point it stops working. Let me clarify that bit -
if the user updates <500 fields then up pops the progress meter and
works great. If the user updates>500 fields then no progress meter at
all - even though the code runs perfectly.

So just to check this out I put a timer event on both the main form
and the progress meter form that would cause a box to flash every 1/2
second. Again this works perfectly until the user tries to update >
500 and then they stop until the code has run (on both the main form
and the progress monitor form). Once the code has run they come back.

My code for the update is below:

Do Until rstClone.EOF
Design_No = rstClone.Fields(1)
For Each fldClone In rstClone.Fields
If fldClone.Value <> rstNow.Fields(fldClone.Name).Value Then
pCount = pCount + 100 / tCount
'Keep user informed of progress by updating the progress
bar in the form frmSaving
If pCount <= 100 Then
'Update the progress bar
Forms!frmSaving.axPBar = pCount
'Try everything to get the progress bar to move!!!
Forms!frmSaving.axPBar.Requery
Forms!frmSaving.Refresh
End If
'Record changes in table History
RecHistory Design_No, fOSUserName, fldClone.Name,
fldClone.Value, rstNow.Fields(fldClone.Name).Value, Date & " " & Time
End If
Next
rstClone.MoveNext
rstNow.MoveNext
Loop

I did use the DoEvents call but this just crashed the whole thing.

Any ideas how to get this to work?

Tony

 

[mcescher]

Hi,

I have a form where a user can update a lot of data, which once they
have finished will record the changes. Just to let the user know that
something was happening I had a progress meter appear. As the updates
are done through VBA and not running a query I am able to calculate
the number of records to be changed and thus update the progress meter
with 100th increments. I am using the MSComctlLib.ProgCtrl.2 Active X
progress bar 6.0.

This all works fine until the number of records being changed gets to
around 500 at which point it stops working. Let me clarify that bit -
if the user updates <500 fields then up pops the progress meter and
works great. If the user updates>500 fields then no progress meter at
all - even though the code runs perfectly.

So just to check this out I put a timer event on both the main form
and the progress meter form that would cause a box to flash every 1/2
second. Again this works perfectly until the user tries to update >
500 and then they stop until the code has run (on both the main form
and the progress monitor form). Once the code has run they come back.

My code for the update is below:

Do Until rstClone.EOF
Design_No = rstClone.Fields(1)
For Each fldClone In rstClone.Fields
If fldClone.Value <> rstNow.Fields(fldClone.Name).Value Then
pCount = pCount + 100 / tCount
'Keep user informed of progress by updating the progress
bar in the form frmSaving
If pCount <= 100 Then
'Update the progress bar
Forms!frmSaving.axPBar = pCount
'Try everything to get the progress bar to move!!!
Forms!frmSaving.axPBar.Requery
Forms!frmSaving.Refresh
End If
'Record changes in table History
RecHistory Design_No, fOSUserName, fldClone.Name,
fldClone.Value, rstNow.Fields(fldClone.Name).Value, Date & " " & Time
End If
Next
rstClone.MoveNext
rstNow.MoveNext
Loop

I did use the DoEvents call but this just crashed the whole thing.

Any ideas how to get this to work?

Tony

If your code sits in the form, you don't need to reference the form.
"Forms!frmSaving.axPBar" should be "axPBar"

You don't need to requery or refresh just to see updates to the bar.
(Your code doesn't suggest any other reason for them to be there)

You can set the maximum value to something other than 100. If you
have 523 updates to make set axPBar.

axPBar = tCount

As long as pCount <= tCount, you're fine. Just check for it.

Set a breakpoint and cycle through the code one line at a time. Set
one by pressing F9 on a line of code. It will turn red, and when you
run the code it will stop at that line. You can hover over variables
to see their value at that point in time. Use F8 to single step
through the lines of code, and then you can see what is happening to
your variables. This can be time consuming, but very helpful.

HTH,
Chris M.

 

[tony]

The code is actually part of a called function which sits in it's own
module, so in order to refresh etc (which although you may think you
wouldn't need to do it actually had the desired effect on small
updates) I have to reference the form as shown. I didn't have to set
the upper value in the progress bar because by dividing the pcount by
100 I got 100th intervals (in some cases the final increment may have
hopped over 100 but the code caters for this).

Thanks for replying anyway but the main problem it appeared was that
the running code was occupying so much of the Access resources (stack
etc I assume?) that it just wouldn't show the form or indeed allow any
timer interupts to run.

Anyway solved the issue by binning the Active X progress bar (which
seems to be the advice given in most posts regarding progress bars)
and using another somewhat more elegant solution found in other posts.

Thanks

Tony