>I tried that and I doesn't change that much because while Visual FoxPro >processes a method, the click is recorded and Visual FoxPro will only fire >the click when the application interface becomes available. So, when the >method is finished, the click will fire and will start another process. > >What I did is something like this in the Click(). > >This.Enabled=.F. >ThisForm.MyProcess() >This.Enabled=.T. > >So, what happen is until those 3 lines are not finished, the application >interface is not available. So, the This.Enabled=.T. will fire before the >click of the mouse is processed by Visual FoxPro. > >The problem remains. Any more suggestions? There was a similar problem with OKL routines - no matter how you prevent them from being called more than once at a time, there's always some wise guy who sets autorepeat on the keyboard rather high with a minimal delay time, and the interface had a silly logic that initiating a new OKL process came before the first process ever had a chance to execute a single line. So, no matter how you forbid recursive (or rather repetitive) OKL calls, someone leaning heavily on a key bombed your app with "Do nesting too deep". I've never found a way to prevent this, so I largely avoid OKL functions. With OKL there were some tricks available, like Set TypeAhead to 0, but with the mouse (which is largely under Windows control now) I see no good way out. Is the old Set Mouse Off still available?