>>>>The right tool for the right job. Right? Sometimes PUBLIC is most desirable, and my response to Koen was
>>>>to his comment "don't use public," which I do not believe is good advice as it immediately shuts people off
>>>>to the idea of ever using a PUBLIC definition, when using PUBLIC definitely has its place.
>>>
>>>That does not mean use every tool. Name one time where public is the most desirable.
>>
>>goApp.
>>
>>
>>>There is one assumption that should be conveyed to you. If you are advising someone who cannot
>>>debug this problem on his own, then you should not be advising him to use public.
>>
>>Personally I think that's a bug in Visual FoxPro. And by the OP's description, it's something that happens on only one machine suggesting it might be an issue with a service pack, for example. Declaring something PUBLIC should be allowed at any time without a prior RELEASE. Visual FreePro will allow it, thereby gladly breaking backward compatibility of that bug. :-)
>
>What happens to the state of existing instances of the variables within the call stack? -- especially in the case where there may be different instances with different values. I'd suspect there might be other weirdness if any of those instances were being passed as parameters.


Nothing. Whatever is in scope is supplanted. Everything else remains and, when it returns to being in scope, is referenced as it should be.