🚀The world's best VBA AI has evolved. ExcelMaster is now an autonomous Agent.Read more →
Back to Blog

VBA ScreenUpdating in Excel — Stop the Flicker and Speed Up Macros (and Why It Won't Fix a Slow One)

|

VBA ScreenUpdating in Excel — Stop the Flicker and Speed Up Macros (and Why It Won't Fix a Slow One)

TL;DR — Application.ScreenUpdating = False tells Excel to stop repainting the screen while your macro runs and redraw once at the end. That kills the flicker and gives a modest speed-up — but only when your code writes to cells, selects, or scrolls. It does nothing for a macro that is slow because of recalculation or file I/O. Set it back to True when you finish, and never rely on it resetting itself — a crash can leave the screen frozen and gray:

Sub PaintRows()
    Application.ScreenUpdating = False        ' stop repainting - no more flicker
    On Error GoTo CleanExit                    ' so a crash cannot strand the screen
    Dim i As Long
    For i = 2 To 5000
        Cells(i, 1).Interior.Color = IIf(i Mod 2 = 0, RGB(240, 240, 240), vbWhite)
    Next i
CleanExit:
    Application.ScreenUpdating = True         ' always restore, even after an error
End Sub

Every time your macro changes a cell, Excel wants to redraw the screen to show it. Do that 5,000 times and you are paying for 5,000 repaints the user never needed to see. ScreenUpdating = False batches them into one repaint at the end. This guide is built on one idea — ScreenUpdating is a repaint switch, not a magic speed switch. It removes redraw work, and only redraw work. Understand that and you will know exactly when it helps, when it is a waste of a line, and why leaving it off after a crash is the real hazard.

What you'll learn

  • The mental model — Excel repaints after every change; this switch batches redraws into one
  • Where it actually helps — writing, selecting, scrolling — and where it does nothing
  • The rule that matters most — a crash can strand the screen, so restore it in an error handler
  • The nested-restore flicker trap — why the screen still flickers after you turned it off
  • How it pairs with Calculation and EnableEvents
  • ScreenUpdating vs DisplayStatusBar and the other cosmetic switches

The mental model: Excel repaints after every change

By default, Excel keeps the screen in sync with the workbook in real time. Your macro sets A1, Excel repaints; it sets A2, Excel repaints again. Each repaint is cheap on its own, but in a loop that touches thousands of cells the repaints dominate — and you see the screen thrash as the macro scribbles down the sheet.

Application.ScreenUpdating = False suspends that. Excel keeps updating the workbook in memory but stops drawing it. When you set the property back to True (or the macro ends), Excel repaints once, and the finished result appears in a single clean jump. The user sees the before and the after, never the flicker in between.

Application.ScreenUpdating = False   ' Excel stops drawing (it keeps working)
' ... thousands of cell writes happen invisibly ...
Application.ScreenUpdating = True    ' one repaint shows the final state

Where it actually helps — and where it does nothing

This is the part most tutorials skip, and it is the whole point. ScreenUpdating removes redraw work. If your macro is slow for some other reason, turning it off changes nothing.

It helps a lot when your code:

  • writes to many cells in a loop,
  • uses .Select / .Activate (each selection is a repaint),
  • scrolls, or changes what is visible on screen.

It does nothing when your macro is slow because of:

  • heavy recalculation after each write — that is Calculation's job,
  • reading or writing files, querying a database, or calling a web service,
  • pure in-memory work on arrays and variables (there is nothing to repaint).

So if you added ScreenUpdating = False and the macro is still slow, you reached for the wrong switch. The single biggest real-world speed-up is usually not this at all — it is replacing a cell-by-cell loop with one array read and one array write, which removes the repaints and the per-cell overhead in one move. ScreenUpdating is the finishing touch on top of that, not the fix by itself.

The rule that matters most: a crash can strand the screen

Here is the failure everyone hits. You set ScreenUpdating = False, your macro errors halfway through, and execution stops — before the line that turns it back on. Excel is now sitting with screen updating disabled. The window looks frozen, half-drawn, or plain gray; ghost images of dialog boxes linger. Users force-quit Excel thinking it crashed, when all that happened is a switch was left off.

You will read that Excel resets ScreenUpdating to True automatically when a macro ends. Sometimes it does — but you cannot design around "sometimes." When the macro errors rather than ending cleanly, or when you are stepping through in break mode, the screen stays stuck. Microsoft's own guidance is to set it back to True yourself. So the rule is simple: restore it in an error handler, so it runs whether the macro succeeds or blows up.

Sub SafeRepaint()
    Application.ScreenUpdating = False
    On Error GoTo CleanExit
    ' ... work that might raise an error ...
    Cells(1, 1).Value = 1 / 0        ' boom
CleanExit:
    Application.ScreenUpdating = True ' this runs even after the error above
    If Err.Number <> 0 Then MsgBox Err.Description
End Sub

The On Error GoTo CleanExit / label pattern is the same discipline the whole cluster shares — see VBA On Error. Without it, one unhandled error turns a speed optimization into a support ticket.

The nested-restore flicker trap

A subtler bug: you turned ScreenUpdating off, but the screen still flickers. The usual cause is a called sub that sets it back to True.

Sub Outer()
    Application.ScreenUpdating = False
    FormatBlock              ' this sub turns it back on - repaints resume here
    WriteTotals              ' flickers, because updating is on again
    Application.ScreenUpdating = True
End Sub

Sub FormatBlock()
    Application.ScreenUpdating = False
    ' ... formatting ...
    Application.ScreenUpdating = True   ' <-- the culprit: re-enables it for the caller too
End Sub

ScreenUpdating is a single global setting, not a stack. When FormatBlock sets it back to True, it is True for Outer as well, and every write after the call repaints. The fix is to let the top-level macro own the switch and have helper subs leave it alone — or have each helper save and restore the value it found rather than hardcoding True. The same "save what it was, restore what it was" habit is what keeps Calculation safe too.

ScreenUpdating vs the other cosmetic switches

ScreenUpdating has quieter cousins. Application.DisplayStatusBar = False and Application.Calculation = xlCalculationManual are often set together for speed, and Application.EnableEvents = False for correctness. But be clear about which does what: ScreenUpdating is purely cosmetic and cheap to forget — the worst case is a frozen-looking window that a restart fixes. Calculation left off leaves silently wrong numbers, and EnableEvents left off leaves the workbook's events dead. They look alike in code — three = False lines at the top — but the cost of forgetting each one is wildly different. Treat all three as "must restore," and know why the stakes differ.

How ExcelMaster helps

ScreenUpdating is one line, but using it well means knowing when it helps (screen-bound loops), when it is wasted (calc-bound or I/O-bound work), and always restoring it in an error handler so a crash does not strand the display. That is a surprising amount of judgment for a single property.

ExcelMaster writes the fast version by default. Ask it to "color every other row across 5,000 rows," and it batches the work, wraps ScreenUpdating (and Calculation, and EnableEvents when events are in play) in a CleanExit restore, and skips the switch entirely when the macro is not screen-bound. You get the speed-up and the safety without memorizing which lever fixes which kind of slow.

Frequently asked questions

What does Application.ScreenUpdating = False do in VBA?

It tells Excel to stop repainting the screen while your macro runs. Excel keeps updating the workbook in memory but does not draw the changes, which removes the visible flicker and the per-repaint cost. When you set ScreenUpdating = True again, Excel repaints once and the final result appears in a single jump.

Why is my macro still slow after setting ScreenUpdating = False?

Because ScreenUpdating only removes screen-redraw work. If the macro is slow because of recalculation, file or database I/O, or per-cell loop overhead, disabling repaints changes nothing. Set Application.Calculation = xlCalculationManual for calc-heavy macros, and replace cell-by-cell loops with a single array read and write for the biggest gain.

Do I have to set ScreenUpdating back to True?

Yes — set it back explicitly. Excel sometimes restores it when a macro ends cleanly, but not when the macro raises an unhandled error or you stop in break mode, which can leave the screen frozen or gray. Restore it in an error handler (On Error GoTo CleanExit with Application.ScreenUpdating = True in the label) so it runs whether the macro succeeds or fails.

Why does the screen still flicker even though I turned ScreenUpdating off?

Usually because a called sub sets ScreenUpdating = True before returning. It is a single global setting, so a helper that re-enables it does so for the caller too, and every write after the call repaints. Let the top-level macro own the switch, and have helper subs leave it alone or save and restore the value they found.

What is the difference between ScreenUpdating, Calculation, and EnableEvents?

All three are Application switches you turn off to make a macro faster or safer, but they control different things. ScreenUpdating stops screen repaints (cosmetic, cheap to forget). Calculation stops formula recalculation (leaving it off shows stale numbers). EnableEvents stops event handlers firing (leaving it off breaks the workbook's events until Excel restarts).

Tested in

Tested in: Excel 365 (Windows 11), VBA 7.1 — last verified 2026-08-17.

Related guides: VBA Calculation · VBA EnableEvents · VBA On Error · VBA For Loop · VBA Range