Public variables at module level are thread specific. Each new thread starts get a new fresh & uninitialized copy of such variables. All the activities that are born from the same object context always run in the same apartment (You can confirm this by checking the thread ID) as if the object context had some kind of thread affinity. What i mean is this: suppose you have an MTS/COM+ object that has a method that returns the thread ID and then calls SetComplete. Each call to the method starts a new activity but the thread ID returned is always the same. This could sound tempting to store some state across activity boundaries but since the number of thread available for a package is limited (100 by default) you would end up having, under heavy stress, different activities sharing the same apartment and then the same public .bas variables. with unpredictable results.
This tip is taken from the FAQ list that Enrico mantains at his own home page (www.sabbasoft.com/mts_faq.htm).
