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

As Christian pointed out, there are alternatives, making your examples of public not the only way to handle things. PUBLIC is - in my experience - very often a lazy choice to do things which could be done better.