Yes, I’m being a bit glib by saying “ you never know exactly what DoEvents() is going to do.” But the example you give about a starting a thread for a mouse move is interesting. Obviously, you wouldn’t need to create a thread at this point (even a BackgroundWorker just borrows one from the thread pool, and you’re free to manage your own threads however you want). But if you were to use DoEvents() in a mouse move event handler you would be on even shakier ground, because the prime danger is with DoEvents() is re-entrancy. For example, you could trigger a cascade of mouse move events and DoEvents() calls which stay open and exhaust the stack. (Not just theoretical, I’ve definitely seen that one happen before, and yes it was in ancient code and it wasn’t particularly well written.) The same problem plagues key press events when a key is held down, and affects painting events, which is where a naïve programmer might think DoEvents() will help remedy their problem. Sometimes the problem that happens is in the sequencing of these events, which isn’t always deterministic, and makes debugging lots of fun.

Of course, there are plenty of ways to shoot yourself in the foot with programming, certainly not limited to DoEvents(). But I’m included to say that’s what BackgroundWorker is there for, and WebWorker in JavaScript — in both cases the threading and message-passing infrastructure is abstracted away and it’s basically impossible to cause a stack overflow just because you tried to make the UI more responsive.

(Standard disclaimer: No disrespect intended. You make good points!)