>Thanks Paul. I guess I gave the wrong impression. I really need an answer to this one.

And I gave you a real answer. :) VFP is not multithreaded. So, there cannot be two threads running in the same time. That means that if one timer method is fired, that method will finish before anything else can happen in VFP. So, any other Timer method will wait until the previous one ends.

The difficult part here is to be sure that all Timer methods are fast enough to not jam. So, if you have 2 timers with the Interval of 1000 each, any Timer method must be shorter than 500ms in the worst scenario. In practice, it must be even shorter because the OS also consumes some time and there may be other processes running.

If your your timer methods take too long, the timer events will stack up and your app will be jamed. Since you cannot control what other processes run on the computer, it's pretty impossible to be 100% sure that this will never happen. So, if your app runs "on the edge", you should provide a mechanism to stop all timers (or selectively, based on priorities, for ex.). This can be easily done using flags (in a database) and a different app that can switch them on/off. (It has to be a different app because otherwise... it would be impossible to reach it since the app is already jamed.)

>What I meant is does each (thread) of the call from the timer store the variables separately? For eg, if Timer1 fires first, FromTimer will be 1. Function updtone will be run. If this takes longer to complete than updttwo, and in the meanwhile timer2 fires, passing 2 as the parameter, will the IF statement, just below the DO CASE, be affected by this change in the value of "FromTimer"?

So, this cannot happen while VFP is single threaded. Even if it were multithreaded, it should work correctly if you use only local memvars (params are local).

>If the value of FromTimer is tested in updtone, as part of the function AFTER timer2 has fired and passed the param 2 to FromTimer, will it hold as 1 or now be 2??

So, if it were on two threads, you would have two copies of local data (and code maybe). It should work correctly.

Now, if you can't wait until VFP will be multithreaded, you can write your app with only one timer and run multiple copies of the same app (one for each task). In this scenario you have multi processes, not threads, and the memory spaces for different processes are completly separated. Any comunnication between processes (instances of your app) must be implemented using files, memory mapped files or other interprocess memory sharing technique.

This method may be much better if you don't really need complicated communication between the multiple instances. It's better because:
- even if one instance jams, the other will still run fine
- Windows will manage the time sharing, so, you don't need to worry about it
- your code can be simpler

Vlad

Vlad