>>>>>>Tom Rettig's envlib.prg does this in .init() - saves the current value to this.oldval, and sets the date (or any other setting, there's a subclass for each) to whatever is passed as parameter to init. Pretty much the same idea, but saves you one line when calling - and that's 50% of the lines you need to write :).
>>>>>
>>>>>Now the question is, do it in Load() (as Naomi) or in Init() (as Tom Rettig). And, if you know, is envlib.prg available anywhere for download?
>>>>
>>>>His classes do that in their .init()s, and you create them in your form's .load() and assign them to some property of something on your form (or the big object with all the settings) so they have a reference on the form and don't revert everything when they get out of scope.
>>>>
>>>>Attached...
>>>
>>>Honestly what concerns me with the class approach of "dealing" with dates (and other settings) is the fact that objects have to be destroyed. And if I don't do it correctly (which most likely I won't :), I will have cases of what I think is calling dangling references. Using a function has disadvantages (as correctly pointed) but it make the code more stable. IMHO.
>>
>>It's actually hard to create a dangling reference, unless you get into some complicated scheme (e.g. two objects keeping references to each other in their properties). If you keep just one reference to it (as in thisform.oSettings), it destroys cleanly, no worries.
>
>But if you create this reference .oSetting (in LOAD or in INIT), don't you have to set it to NULL in Destroy method of the form?

That's usually only an issue if the reference object has a reference to the creating object. That is, if oSetting has a reference back to the form.

Tamar