Solved: userform not catching up

[philfer]

Hi,

I am using a userform as a progress indicator.

However when my code shows the form it is completely white and doesnt seem to ever catch up with the process.

If I run through my code line by line using F8 it works just fine. However when I try to run it using the macro button it is blank.

It is almost like it needs a little time to initialise before it gets going but is not having the time to do so.

Can anyone help

[Bob Phillips]

Try launching the main code from within the activate event of the form, i.e. after it is rendered.

[johnske]

And use DoEvents

[gwkenny]

I'm ASSuMEing you do this the same way I do, with a modeless UserForm.

I've always had to repaint afterwards:

frmProgress.ProgressBar.Value = 20
frmProgress.Repaint

[johnske]

I'm ASSuMEing you do this the same way I do, with a modeless UserForm.

I've always had to repaint afterwards:

frmProgress.ProgressBar.Value = 20
frmProgress.Repaint

don't think it's quite the same... DoEvents yields execution so that the operating system can process other events (such as unloading a macro dialog box - which seems to be the case here) Repaint may delay that processing.

[gwkenny]

This is interesting. If the OP is using a progressbar object, he's updating it rather than unloading a form. The system never has a chance to automatically repaint as the processor is tied up executing code.

I'd expect repaint would be faster because DoEvents would enable the computer to repaint the screen as well as any other process submitted into the queue by any other applications before it returns control back to the code. Repaint just forces that one issue without giving up control.

Unfortunately I've moved to a new box and can't test this quickly

[johnske]

...If I run through my code line by line using F8 it works just fine. However when I try to run it using the macro button it is blank...

I take "using the macro button" to mean using the "Run" button on the macro dialog box, which then needs to be unloaded prior to showing the userform and running its code, if it's not unloaded - and this requires DoEvents (delaying the running of any of your own code by yielding to Visual Basics and the O/S code requirements to unload the macro dialog box) - it's quite typical for the form to often come up white as described by the OP while the two bits of code are running in tandem ... Repaint demands an immediate repaint.

[gwkenny]

Ahhhh,

Enlightenment comes slow to some folk

Now, after the second explanation (though you were very clear in the first one with stating "unloading the macro dialog box") I understand exactly what you mean.

Though I still don't know if repaint would be slower because a progressbar Userform usually doesn't have much on it besides the progressbar object. With DoEvents it's going to suspend execution to repaint the progressbar object and do anything else in the processor's queue. Yes repaint demands an immediate repaint of the progressbar object and the Userform around it but it's not going to suspend execution till everything in the processor's queue is completed.

In a perfect world, I'd agree with you cause the only thing that should be in the processor's queue is the screen repaint. Windows has so much overhead though, especially in a company networked environment, I'd still imagine DoEvents has to be slower.

Thankfully, I think the differences we are talking about are unobservable to the User

[Bob Phillips]

It is not a question of which is faster or slower, it is a question of which works. Repaint won't because it will not get the processiong slot.

[philfer]

After all that I'm not sure what the answer is as everyone keeps disagreeing!!

I use repaint and launch the main code from the userform activate event

With all that it still does what I mentioned at the beginning

Cheers
Phil

[Bob Phillips]

Post a workbook and let us see.

[gwkenny]

Repaint works.

It has to get the "processing slot" because it's called by the process that's creating the jam, and that's the Excel app executing code. Since that process is dominant by default since it's creating the jam, the computer is forced to repaint as that's the process it's executing.

IF it does pause for any reason, then the whole Excel app processing thread is paused and nothing is getting done with regards to Word as something else is being processed. DoEvents is definitely not going to yield better results.

Logically, how can it not work???

The real proof is in the pudding. The pudding in this case is the fact that it has worked for a long long period of time in my code at several institutions.

Try it, you might be surprised

[gwkenny]

After all that I'm not sure what the answer is as everyone keeps disagreeing!!

I use repaint and launch the main code from the userform activate event

With all that it still does what I mentioned at the beginning

Cheers
Phil

The final straw is you use what works. If repaint doesn't try DoEvents. Though I can't understand why it wouldn't work for you but it does for me and all of my client machines.

It would be hilarious though if there's an application.screenupdating=false somewhere that negates the use of repaint or doevents!