> > Hi Ilya
> >
> >
> > A better solution may be to have a form manager object which contains references to all forms. No publics required. I tend to think people are just not trying hard enough to avoid PUBLIC vars. :)
> >
> > Mike Yearwood
> > www.foxridgesoftware.com
> > President: Toronto Ontario FoxPro User's Group
>
> Good morning, Mr. President! (;>) (Sorry, can't help it...)

No problem - I'll assume you're not being sarcastic. ;)

> I'm afarid I haven't made myself clear enough: the method of storing references is of no concern, but keeping these references 'alive" is. And, if you have to create, in a procedure or a function, multiple instances of the same form, and you have to have those references available for any other proc/func/method/event for the entire form's lifetime... I do not see at the moment how it can be done without making the forms' instances' names PUBLIC.
> You can DO FORM "frmData.SCX" NAME frmDat_APPID_DocKey in a FUNCTION or PROCEDURE, but that would be implicit declaration of the memvar frmDat_APPID_DocKey; thus, once you RETURN, frmDat_APPID_DocKey will be discarded. What's the "fate" of your instance of the frmData would be then?

Have a form manager object issue the DO FORM command for you. The form manager object can have an array property. Then you simply

m.lnPointer = ALEN(THIS.iaForms,1) + 1
DIMENSION THIS.iaForms[m.lnPointer]
DO FORM (m.tcPassedFormName) NAME THIS.iaForms[m.lnPointer,1] LINKED

Now the form stays alive until the form manager is asked to release it. No public vars!

> Unless I greatly misunderstand the concept of scope, or lifetime, of a memory variable, once the memvar is gone - so is your form's reference (as may be your form object); and if it was LINKED - the object is gone as well (for sure). Thus, saving the name of an object created in a procedure on runtime in whatever container (table, custom class' object) loses meaning if this name/memvar is not visible enywhere in the program; that latter calls for PUBLIC memvar.
>
> Now, to ease your concerns (:>), this is about all cases where I consider the use of PUBLICs justified: locations/directories (like gcTempDir, gcStartDir, gcDataDir), form objects instantiated on runtime, maybe some common settings (like glAdmin) - and that's it!.

Sorry, can't agree! ;)

If you have an application object with such properties - not publicly available, and this object obtains these settings from a file or has them hard coded, the properties can be accessed via a method but cannot be changed by accident.

That's the point. To prevent accidental changes by other application components.

Mike Yearwood
www.foxridgesoftware.com
President: Toronto Ontario FoxPro User's Group