Hi Jim, I hope you don't mind that I did a cut and paste of another reply into this reply. For I'd like to react on some of your words.

>I will tell people that publics are forbidden. IMHO public variables should be removed from the language totally, I will never miss them. BTW I believe strongly that when one is seen as a knowledgable person by others one carries an extra responsibility. If I say PUBLIC or PRIVATE vars are OK it is immediately interpreted by certain folks as permission to create poorly designed applications because PUBLIC and PRIVATE vars are symptomatic of design problems. Privates less than PUBLICS as most applications need at least one global (Private in the startup program) var, the reference to main app object. Declaring a variable PUBLIC is an invitation to disaster and some bugs that are very difficult to isolate.
JimB


I understand that you'll never miss them. But what I don't understand is your use of IMHO. Your standpoint isn't really humble, it's fierce! It's your right to have a strong opinion on the matter, but it's not humble.
I'm not sure what to think of your note that a knowledgable person carries extra responsibility. I understand what you're saying, but most if not all of us here are grownups and experienced developers. You're a colleague who has proven to have a lot of knowledge and insight, but you're not our guru (yes master, no master), at least not mine. I hope you understand what I'm trying to make clear. And it's not your fault if some folks misinterpret your advices. I think you HAVE room here to put things in perspective. However, it might be that having fierce extreme standpoints is part of your image. And such people are necessary for discussions, aren't they?!
I agree that public and private variables are more of a problem than local variables. And you know what? I think that PRIVATE variables are actually far more troublesome than public variables. You'll hardly find any private variable in my programs. I mainly declare them prior to a call of a report, for usage in that report, simply because local variables are out of scope in reports.
BTW, for the first time I noticed your signature "Technical Advisor UT". I've searched on the UT for the explanation. Couldn't find any. Is it a title that Michel gives to some?


>If your application is held up by a READ EVENTS there is no need to declare any variable as PUBLIC. I have seen code wheer the goApp variable is declared public and it does not need to be public. A PRIVATE variable declared prior to the READ EVENTS is visible to every line of code in the application. The ONLY reason to declare a variable PUBLIC is if it needs to be referred to after the declaring program ends and that is of itself a design problem (that the var needs to be referred to after the declaring program ends).
>
>There is only one situation where I declare any var public. That is when I run an application in my debug mode where the reade events is bypassed to allow the command window to reappear and allow access to the debugger and the other utilities of VFP. My startup program is something like this;
>
>

>LPARAMETERS tlDebug
>
>IF tlDebug
>   RELEASE goApp
>   PUBLIC goApp
>ELSE
>   PRIVATE goApp
>ENDIF
>goApp = CReateObject("TheMainAppMgr")
>IF NOT tlDebug
>   READ EVENTS
>ENDIF
>

>
>That is the only time the goApp is declared public and it is because I need goApp to survive past the end of the Startup program. When not in debug mode it is not necessary to make the goApp public because the PRIVATE will not go out of scope until the CLEAR EVENTS is executed.


Hmm, in my main program I always do a Read Events. I'll try your method.
As I read the sequence of commands, the final application (presumably an EXE) uses private and Read Events. But isn't it a fact that after the Clear Events the application will simply end? What harm can public variables do then?
There's another thing that came to my attention. In both cases you use g for the variable. I guess you regard it to stand for GLOBAL?! That makes sense, the programmer may assume that all g-variables, whereever encountered in the code, have been declared in the main program. That would be a nice RULE. However, it's not the rule that the documentation proposes. The documentation proposes to use the g for public variables. No big deal for me. I'm sure you've documented it. :)