>>Don't think so. PRIVATE is really a compiler directive, not actually creating the variable unlike LOCAL or PUBLIC. Easy enough to demonstrate:
>>
>>

PRIVATE myvar
>>? myvar

>>
>>If a (declared or by default) Private variable exists when a proc or function is called, it can be manipulated there unless passed as a parameter by value or declared local or private there. If the variable does not exist but is created in the called function or proc, by default it is created private to that sub-proc, so its value is lost at the end of the proc.
>>
>>

PRIVATE myvar
>>*---uncomment this to compare:
>>*---myvar=""
>>=Test()
>>? myvar
>>
>>FUNCTION Test
>>myvar="I think, therefore I am."

>
>As I understand it, PRIVATE creates a shadow of the global variable which exists from that point forward in the call structure, but upon returning from whatever the context is (function, method, event), it goes out of scope and the original value defined PUBLIC is once again visible.
>
>I don't view it as a compiler directive. In Visual FreePro, I had to add contextual variable lookups to support PRIVATE variables.


Building on this thought, you may want to get with with Chen to see if he couldn't auto-inject the PRIVATE _TALLY source code equivalent each time an event is triggered, so that _TALLY is not clobbered by some event-based code. It would only be injected when an event is fired from VFP, and not from direct source code.

This would, of course, be enabled by a new SYS(...) setting which allows it.