>>George, that's clever and I'll certainly use it whenever appropriate (appropriate according to me). However, I see one problem. Jim Booth stated (in other words) that we must guarantee that all variables get out of scope when the application ends, in order to prevent interference in a next run application. Added _screen properties won't get out of scope, so Jim would disagree with this usage?!
>
>Peter,
>
>I wouldn't dream of saying whether or not JimB would disagree. Certainly, however, I'd have to make the point that a global property/object is different from a global mevar. I'd be lying if I said that back in the FPW days, I didn't use the PUBLIC statement, because I certainly did. However, how I used the variables, may have been significantly different than the norm. They were used to hold global constants, that no program ever modified. For example, my applications run at 6 different manufacturing plants. Each plant has a 2 character "number". For example, I work at Plant 15. Some applications run at Plant WE or 11, 12, etc. The applications produce reports. The reports have to show the plant number. So, I used a global variable, initialized by data in a table to store this value. In VFP, I can use a property of the _SCREEN.

George, no problem for me. But a public variable can do as well, can't it? In case I'd intentionally want the value to be omnipresent across applications, I'd certainly use _screen. That reminds me of VarX(), a function I wrote in 1996. An article about it was published in Foxtalk. This function also enabled us to make what I called 'enduring variables'. I guess the _screen.addproperty() feature has made that function obsolete, at least for a part. (http://www.pinnaclepublishing.com/foxtalk/FTMag.nsf/Index/04E151AF88FA48DD852568E90052F28E?opendocument)


>The other thing is that application objects can provide services that all applications may have need of. In this scenario, there's no need to destroy the object when the application changes.

Sure.

>I do believe, however, in what I call "Mom's Rule"..."Put things back the way you found them." Any changes that an individual method may make to the global environment are restored before the method terminates.

Good rule. And IMHO it doesn't disqualify the use of public variables at all.

Jim Booth, and probably others, stated that a publicly required variable in a main program should be declared as private. I know that the effect is the same, however, I make a habit of only declaring variables public - instead of private - in the main program. This enables me to distinguish those variables (g...) from variables that were declared private (p...) elsewhere. And a simple RELEASE ALL LIKE g* in the shutdown routine can almost guarantee that the application will clean up as required.

BTW, I hardly use public AND private variables, but I'll never tell people that they're kind of forbidden.