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

There is not question that public variable, more often than not are being, misused. However I think that Rick hit the nail on the head by outlining that global objects are perfect candicates to be referenced by public variables. In our framework, not only the Applic object is accessed through a public variable, but also objects for:

- Personal settings
- Authorisation
- Dataobjects manager
- Messagehandling
- Event Logging
- DataCache
- MenuEngine
- Reporting engine

Since these are all singletons and part of the framework, it makes sense to use public variables for them.
Whether you instantiate them as private from the main program or public is really irrelevant as far as i'm concerned.

Walter,