>Hi Craig,
>
>In what case is a private variable declared at the main.prg different than a public ?
>Besides the case where you call this main.prg from another VFP application, but since this is (should) be rare I don't really see a difference.
Yes, it is different. PUBLICs can bleed through MTDLLs. By always declaring it PRIVATE, I don't have to do it one way for EXEs and another way for DLLs.
>
>For the record, though I agree you should keep the number of PUBLICs to a absolute minimum, you might need some additional 'switches' that could have application outside the applic object. For example I've got a textbox which appearance is depended on such switch. The textbox could be used in GUI elements that starts before any applic object has been initialized. Think about a variable that holds the number of colours in the display settings. You might need that one to determine which graphic to display in the splash screen.
That's an application design issue. You could just as easily create an application object, then set a property to the value of the parameter.
>
>Also think about my TAX RI builder which produces stored procedures where the RI rules can be overriden by two variables. You don't want these to be depended on a applic object.
Since I don't know how it works, I can't comment any further.
>
>So there might be additional PUBLIC variables in your program that are used for the framework and do have application outside the scope of an applic object.
Yes, there may be, but it's been my choice to not use them. YMMV.
>
>Walter,
Craig Berntson
MCSD, Microsoft .Net MVP, Grape City Community Influencer