I would like to remember some values associated with a form so that on a second invocation of the form things - such as the date range of the report - default to the values I used earlier in the session.

At present I keep all my global variables for my application in a public object, goapp. So in the start program for the application, I say :


and then I create several variables which are of interest across the application


I would like to simulate static variables (which I know do not exist in VFP) for a particular form so that I can refer to them as e.g.


That is, I would like to keep these properties together, rather than saying :


How do I add the object Myauditform as a property of my global variable goapp? And, if I decide to do this in the Init() method of Myauditform, can I check for the existence of goapp.MyAuditform, so that I do not attempt to create it twice?

Hope I am not making too heavy weather of this !

Andrew,

You can only add an object to a container object. In other words, for this to work, you would have to base goApp on a container, for example:


The above is not meant to be fully working code, of course - it's just to give you the general idea.

There are a couple of other ways of dealing with persisent values:

(i) When the user wishes to close the form, don't actually close it, but just make it invisible. Next time they want to open it, make it visible again. That way, it will re-appear just as it was when the user last saw it. But this could cause problems in terms of unsaved edits, so it won't be a good solution for all forms. Also, make sure you close the form properly when the user closes the application.

(ii) Maintain a table for all your persistent settings. Each record will have the name of the setting and its current value. This can be used for just about anything you want to persist, either from one invocation of a form to another, or from one session to another. For example, it can be used to hold each form's size and position, so that these can restored next time. It can also be used for low-volume data such as user preferences.

I use (ii) in all my apps. The table also has a field for user ID, so each user can have his or her own settings.

Hope this helps.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

Thanks Mike. You have put me on the right track.

In fact goapp does not have to be a container. Custom is fine - it can still have an object added to it.


Am I being reprehensible in using the Custom class directly (rather than subclassing it as SettingsClass, and using that)?

Thanks again. Andrew

Andrew,

Quote:

In fact goapp does not have to be a container. Custom is fine - it can still have an object added to it.

You're right and you're wrong. It does have to be a container. But Custom is itself a container, which is why it works. (I was also right and wrong, for not spotting that.)

Quote:

Am I being reprehensible in using the Custom class directly (rather than subclassing it as SettingsClass, and using that)?

Maybe not reprehensible, but certainly open to the scorn and approbation of the world at large. No, I don't really mean that. A purist would use a subclass in these circumstances, but I personally wouldn't bother.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

What you also can do, if it's only about some properties, is to create an object via oMyFormProps = CreateObject("empty"), then add properties to it via Addproperty() function (not method): Addproperty(oMyFormProps,"cProp","Test") and so on and so forth.

Then finally Addproperty(goApp,"oMyFormProps",oMyFormProps) and you have goApp.oMyFormprops.cProp etc.

For that matter goApp could also be a non container class, eg a session class or a timer or a label or whatever else you could think of.

And for the other question: You can check for exsitence of the property by PEMSTATUS().

As a side note: There is a difference of custom to other container classes: You can't visually add another object to a custom class, only via AddObject() method. If you try to visually drop an object on a custom class, the error message you get is "Cannot add objects to non-container classes". Therefore Mike was not that wrong, the cusom base class is only halfways a container class, because it offers the AddObject() method.

The conteiner class as base class of nonvisual classes has it's advantages, even if just to be able to compose a bigger class out of several such container classes and be able to manually set properties at design time in them.

Bye, Olaf.