Roy,
I think it may be helpful to step back and explain a couple of features of the Visual Basic Timer control.
When you create a Timer, set the Timer.Interval, and enable the timer, you have started a process that will “fire” after the interval completes. However, in order for the timer to fire, your foreground process must not be running.
The timer will only trigger the _Timer event procedure if the timer control can gain control of the computer; and it can’t do that if your code is running.
You may have noticed that numerous posts have suggested that you execute the DoEvents method after enabling your timer. This method releases control. It allows any other process that is waiting to run to take control and execute. This normally includes other applications that are running on the computer. However, it also includes the timer.
In other words, it’s not sufficient to execute DoEvents once, and then continue with your processing. You have two choices:
? If your code is running continuously - for example if you are executing a loop that is looking for some specific event before going on with code outside the loop, you must execute the DoEvents method in the loop
? If you code is running only as event procedures in forms and reports - so that your application executes only in response to events, you don’t need to do much of anything. The timer will start the _Timer event procedure, just as other external actions (like the user clicking the mouse on a control) will trigger their event procedures
Let’s look at what you have been experiencing. If you set a breakpoint in your foreground code, it stops running. The Visual Basic Interactive Development Environment (IDE) releases control until you interact with it. Therefore, the timer can gain control and begin its event procedure, which will hit the second breakpoint. Because the IDE is already in the “interact with the user” mode, it won’t actually display the second breakpoint until you resume from the first breakpoint.
On the other hand, if you don’t have the first breakpoint, your code keeps running. Therefore, the timer never gets to trigger its event procedure.
This implies that your code keeps on running. As I stated in the first of the two choices above, you need to insert a DoEvents in the code that continues running. You don’t need a DoEvents in the code that enables the timer. You need one in the code that will be running when the timer fires.
Of course, a far better approach is to redesign your application so it doesn’t keep running. Instead, design it so that it does whatever is necessary to create the user interface, and then releases control (basically, exits from the event procedure that displayed the form or whatever). Design your application so that everything is in the event procedures: everything is triggered by events, runs only as long as necessary, and then releases control. With this kind of structure, your application will have no difficulty responding to the timer. Your application will also be “well behaved” (it will play nicely with other applications). Look at whatever you’re doing in that continuously executing loop, and figure out how to use events to recognize whatever you’re testing for.
Michael S. Meyers-Jouan