>>>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.