You may be misinterpretting what DoEvents is supposed to do. DoEvents is a
release from the application to the operating system. The behavior you note
is characteristic of a pre-emptively multitasking operating system. Saying
DoEvents was you telling the operating system, "I'll hold what I'm doing so
you can catch up with whatever else is going on." DoEvents is also available
in standard VB for the same purpose.

There's an explanation much better than I can provide at
support.microsoft.com/default.aspx

Interestingly enough, they use an I/O function as an example! But if you
read through the whole thing you'll see lots of opportunities for
deadlocking, etc. In the end, they used an approach similar to your
solutions to cleanly handle events.

That would explain why your button wasn't responsive and your serial port
was still being held open for the stream because your code  was also calling
out to the OS to do its thing with serial I/O. The OS had the port and was
watching interrupts everytime you did the DoEvents.

And, as you peppered more DoEvents calls into your code, you may have
experienced some of the following:
"• Using too many nested DoEvents statements may deplete the stack space
and therefore generate an "Out of Stack Space" error message. This error is
referring to the application stack space allocated to the Microsoft Excel
application.
• Make sure the procedure that has given up control with DoEvents is not
executed again from a different part of your code before the first DoEvents
call returns; this can cause unpredictable results.
• Once DoEvents relinquishes control to the operating system, it is not
possible to determine when Microsoft Excel will resume the control. After
the operating system obtains control of the processor, it will process  all
pending events that are currently in the message queue (such as mouse clicks
and keystrokes). This may be unsuitable for some real- time data acquisition
applications."

I'm sure that behavior got better as the OS matured into 2k and XP and
processors got faster(it has on my systems). And your explanation is a good
one for explaining why DoEvents can have unexpected results, though!

Also note that Office apps have a particular hindrance in place as you work
with them. Their rendering engines are a little taxed from having to also
redraw using elements of the printing subsystem. Complex charting, tables in
Word, etc., can bring even the most robust machines to an apparent halt. For
example (and Excel doesn't seem to have this issue, thank goodness), Word
tables of more than a few thousand rows can take an hour to redraw after
adding a single row...and this is on a 1.1 Gig system!

In the orginal problem, I was curious as to whether the
Application.ScreenUpdating toggle has been used. With this, you can greatly
improve performance of the VBA app and only update the screen when you're
ready.