......is this true ??
Which means that it will also be true when stepping through and
executing "?Application.Screenupdating" in the immediate window ?

Regards,
Jason.

Unless you've put

Application.ScreenUpdating = False

in your code.


"WhytheQ" wrote:

......is this true ??
Which means that it will also be true when stepping through and
executing "?Application.Screenupdating" in the immediate window ?

Regards,
Jason.

Hi Jason,

Yes, it's true. The purpose of steeping through your code is to see what
happens as you step. Hence ScreenUpdating is necessary, so setting it to
False has no effect while in break (debugging) mode.

Also, it automatically resets to True when your procedure terminates.

HTH
Regards,
GS

Also, it [ScreenUpdating] automatically resets to True when your procedure
terminates.

I don't believe that's the case. Maybe we're using two different
definitions of procedure. I have one procedure (macro) that calls another,
returns, and calls another. Are you saying that when the first procedure
terminates it's reset to true of that when ANY procedure terminates it resets
to true. I believe it's the former, rather than the latter.

"GS" wrote:

Hi Jason,

Yes, it's true. The purpose of steeping through your code is to see what
happens as you step. Hence ScreenUpdating is necessary, so setting it to
False has no effect while in break (debugging) mode.

Also, it automatically resets to True when your procedure terminates.

HTH
Regards,
GS

Hi Barb,

I apologize if my reply wasn't clear. My reference was to the procedure that
set the ScreenUpdating to False. If you set it thus in sub-procedures, I
believe it persists False until the first procedure terminates unless it is
deliberately reset by a subsequent line of code in a called procedure.

As far as VBA is concerned, code isn't terminated until all procedures in
the stack have ended.

HTH
Regards,
Garry
---

"Barb Reinhardt" wrote:

Also, it [ScreenUpdating] automatically resets to True when your procedure
terminates.

I don't believe that's the case. Maybe we're using two different
definitions of procedure. I have one procedure (macro) that calls another,
returns, and calls another. Are you saying that when the first procedure
terminates it's reset to true of that when ANY procedure terminates it resets
to true. I believe it's the former, rather than the latter.

"GS" wrote:

Hi Jason,

Yes, it's true. The purpose of steeping through your code is to see what
happens as you step. Hence ScreenUpdating is necessary, so setting it to
False has no effect while in break (debugging) mode.

Also, it automatically resets to True when your procedure terminates.

HTH
Regards,
GS

Thanks. On this we agree.

"GS" wrote:

Hi Barb,

I apologize if my reply wasn't clear. My reference was to the procedure that
set the ScreenUpdating to False. If you set it thus in sub-procedures, I
believe it persists False until the first procedure terminates unless it is
deliberately reset by a subsequent line of code in a called procedure.

As far as VBA is concerned, code isn't terminated until all procedures in
the stack have ended.

HTH
Regards,
Garry
---

"Barb Reinhardt" wrote:

Also, it [ScreenUpdating] automatically resets to True when your procedure
terminates.

I don't believe that's the case. Maybe we're using two different
definitions of procedure. I have one procedure (macro) that calls another,
returns, and calls another. Are you saying that when the first procedure
terminates it's reset to true of that when ANY procedure terminates it resets
to true. I believe it's the former, rather than the latter.

"GS" wrote:

Hi Jason,

Yes, it's true. The purpose of steeping through your code is to see what
happens as you step. Hence ScreenUpdating is necessary, so setting it to
False has no effect while in break (debugging) mode.

Also, it automatically resets to True when your procedure terminates.

HTH
Regards,
GS

Thanks for all the help.

J




On 18 Apr, 16:42, Barb Reinhardt
wrote:
Thanks. On this we agree.



"GS" wrote:
Hi Barb,

I apologize if my reply wasn't clear. My reference was to the procedure that
set the ScreenUpdating to False. If you set it thus in sub-procedures, I
believe it persists False until the first procedure terminates unless it is
deliberately reset by a subsequent line of code in a called procedure.

As far as VBA is concerned, code isn't terminated until all procedures in
the stack have ended.

HTH
Regards,
Garry
---

"Barb Reinhardt" wrote:

Also, it [ScreenUpdating] automatically resets to True when your procedure
terminates.

I don't believe that's the case. Maybe we're using two different
definitions of procedure. I have one procedure (macro) that calls another,
returns, and calls another. Are you saying that when the first procedure
terminates it's reset to true of that when ANY procedure terminates it resets
to true. I believe it's the former, rather than the latter.

"GS" wrote:

Hi Jason,

Yes, it's true. The purpose of steeping through your code is to see what
happens as you step. Hence ScreenUpdating is necessary, so setting it to
False has no effect while in break (debugging) mode.

Also, it automatically resets to True when your procedure terminates.

HTH
Regards,
GS- Hide quoted text -

- Show quoted text -