Why Reset ScreenUpdating to True? Here’s Why!
Occasionally a parroted claim will pop up in the Excel cybersphere that resetting ScreenUpdating from False back to True in a VBA procedure is pointless and unnecessary. Supporters of this claim mistakenly believe that VBA “resets itself” at the end of a macro or procedure, and/or not resetting ScreenUpdating to True has no bad effects.
Do not believe these claims — they are misinformed and dead wrong. Whenever you set ScreenUpdating to False in your code, make certain to reset it to True. Here’s why:
First, no matter what the help files may say, or what you may have heard, ScreenUpdating does not always reset itself, including where UserForms and User Defined Functions are concerned. Part of the confusion about this topic comes from versions 2000 and before, when it was not necessary to set ScreenUpdating back to True. No longer the case starting with version 2002. Code writers who did not reset ScreenUpdating to True before 2002 had to go back to their macros and do so.
Second, resetting ScreenUpdating to True is a wise practice to cover your bases. If for example the macro errors out or is interrupted before it completes, ScreenUpdating would still be off while Excel is running. Future versions of Excel will invariably support new, or stop supporting existing, VBA methods and properties, so it’s an unnecessary risk to not reset ScreenUpdating.
Third, there might be times when you are running code in sequence and you want to see what you did while you are doing it. See the following three macros. Macros Two and Three are called by Macros One and Two, but you cannot see the results of your code until the last macro is completed, unless you had set the ScreenUpdating back to the way it was in each macro. It bears mentioning in this case that the message boxes give that wild effect if you drag them while ScreenUpdating is False, very sloppy, all the more reason to set things back to normal as you go.
Sub One() Application.ScreenUpdating = True MsgBox "Screen Updating is on." Range("A1:A3").ClearContents Range("A1").Value = "One" Application.ScreenUpdating = False MsgBox "Screen Updating is off now !!" Two End Sub Sub Two() Range("A2").Value = "Two" MsgBox "ScreenUpdating is " & Application.ScreenUpdating Three End Sub Sub Three() Range("A3").Value = "Three" MsgBox "ScreenUpdating is " & Application.ScreenUpdating End Sub
Fourth, good code writing in my opinion involves good citizenship and an awareness of perception. If you change the setting of something, then when you are through, set it back to the way it was before. Whatever I set, I reset. Whatever I define, I undefine. You never know when the next version from Microsoft will make you wish you had the good sense to keep things in order from the start. It’s sloppy coding to not re-set what you changed. Fair or not, just as people are judged by how they write and speak, programmers are judged by the quality of their code, and seen to look lazy and VBA-ignorant when not re-setting the application.
There are too many bad possible outcomes that you would not know about until they happen. Platforms; IT settings; UDFs; fatal errors occurring from unforeseen reasons (but they’d seem obvious after they happen when first unforeseen); the list goes on. Not setting ScreenUpdating to True is a bad risk. I cannot tell you how many times in my work I’ve come across a potential bad outcome were the True setting not reset.
Whether the end of a macro comes from the expected process of events or through error handling, please always ensure you have reset ScreenUpdating to True if you had previously set to False.