It is impossible to say based on how little you've posted whether that is  
in fact causing your problem.

But you should certainly remove it and fix your design to work without it,  
as calling DoEvents() certainly _can_ cause, or at least be related to,  
problems such as what you've noticed, among other things as well.

Frankly, a call to DoEvents() does not belong in any well-written  
program.  If you start with bad code, it may sometimes be the most direct  
way to work around a problem, but it's always better to solve the problem  
(which is usually that of trying to run concurrent tasks) correctly  
instead of calling DoEvents().

The main GUI thread should be used only for the user interface, and for  
relatively short tasks (i.e. ones that the user will not perceive as  
interfering with the user interface).  In some very limited scenarios, you  
may go ahead and block the GUI thread, but you should do so understanding  
that the user won't be able to interact with the UI.  Otherwise, use one  
of the several multi-threading classes available in .NET to put the longer  
tasks on a thread other than your GUI thread.

If you introduce DoEvents(), then now you have ways for the main thread to  
reenter code that's already running, which can cause a variety of problems  
including the "multi-click" problem you're seeing.  Normally this would  
only happen as a result of user input, but it's not the only way, and in  
any case it sounds like you haven't ruled out reentrant user input as a  
cause of the problem.

You can address some of these reentrancy problems, but it's not going to  
be any easier to do that than to handle the synchronization issues that  
might come up with a multi-threaded solution.  If you're going to write  
code that's more complicated, you might as well write _correct_  
complicated code instead of incorrect complicated code.

Pete