Demystifying DoEvents
If you've spent any time programming in Microsoft Access, you've likely run into a situation where the screen dimmed and the application title bar got updated to include the text "(Not Responding)." After some Googling, you also probably found the simple solution: add a call to DoEvents
.
The DoEvents
function was largely a mystery to me for a long time. I used it much like a cargo cult programmer would. Whenever the screen dimmed and I got the dreaded "(Not Responding)" text in my application title bar, I would start throwing DoEvents
calls into my code all willy-nilly.
Still "(Not Responding)"? Let's throw some more DoEvents
calls into the mix.
I was like Oprah celebrating an episode milestone, but instead of guests I was shouting to my procedures, "You get a DoEvents
call. And you get a DoEvents
call. And you get a DoEvents
call!"
Needless to say, typing random code into your editor in the hopes of appeasing the Microsoft gods is no way to develop software.
In this series of articles, I'll dive deep into the DoEvents function. I'll demystify this function so that you can start using it with intention, instead of haphazardly the way I used to still do sometimes.
I'm going to explore the following topics:
- What is DoEvents
- Where to Use DoEvents
- When to Use DoEvents
- Why it Works: A High-Level Overview
- How it Works: The Nitty-Gritty Details
UPDATE: Bonus Articles!
And hopefully, if all goes well, you will finally be able to get rid of those wooden headphones you've been keeping around "just in case."
Base Image by Susie Bailey from Pixabay (wooden ball Image by GGs_ from Pixabay) – cartoonishly bad combination of the two images by Mike Wolfe from NoLongerSet
External references
Article references
Image by PublicDomainPictures from Pixabay
UPDATE [2021-07-21]: Added link to bonus article, DoEvents vs. Repaint