>Trying gamefully to eliminate as many public variables from my legacy 2.6 app as possible by replacing them with form properties - but have come across a couple of problems.
>
>example 1 - skipping system menu options on basis of value of public variable. The menu can't "see" the form properties.
>
>example 2 - macro substitution doesn't work with form properties. Ferinstance, I have (up to now) a public variable called 'filt_expr' to hold the value of the current filter expression. This allows me to use code like SET FILTER TO &FILT_EXPR.
>
>but "set filter to &thisform.filt_expr" isn't allowed, so in order to achieve the same result using a form property I now have to do:
>
>if not empty(thisform.filt_expr)
> tempfilt=thisform.filt_expr
> set filter to &tempfilt
>endif
>
>which is not exactly an improvement! And given that I use the original version about 300 times throughout the app, frankly I'd rather stick to the public variable.
>
>Someone please tell me there's a better way which is in line with the OOP paradigm!
>
>Harry

Hi Harry,

Global data are usually stored as properties of a global application object, rather than a form. The Global app object might also manage tasks such as security and menu/form management.

At the start of an app, the app object can be created and assigned to a global variable (hopefully the only one).

e.g.
PUBLIC goApplication
goApplication = CREATEOBJECT("cusApplication")

All subsequent references can be made via the public variable. For example, whenever my app needs to show a form, the request will go through the FormManager object which (in my framework) is a child of the application object.
e.g.
goApplication.FormManager.CreateForm("Customer", lnCustId)