Hi,

I have an "environment" object, now a subclass of sficcst, that remembers and sets various settings, e.g. it stores set("date") to this.OldDate in the Init and restores the setting in the Destroy of the class

OldSetting = this.OldDate  
set date &OldSetting

This class is instantiated as a public variable during startup and also instantiated and saved to a property on every form with a private data session during the form's Load().
This property is included in the form's wcPropSave.
The object also has its wcpropsave set during its own Init() to include all of its properties.

I have discovered that when WC is shut down and the SficServer class is destroyed, each instance of the object is being destroyed as expected when the parent objects are destroyed, but there is one occasion (when the wait window "awSets().Destroy is restoring your..." appears) where all of the properties are empty during the Destroy event and this will cause set date &OldSetting to error. Once this happens things go bad and VFP becomes unstable...
Even though in lan mode there would only be two instances during my testing, one public and one on the login form, in web mode I see about 6 instances being destroyed during shutdown! Somehow, the properties of one instance of the object are not being restored (I assume they were set correctly during the Init() ).

Any ideas what could be wrong?

Thanks
Paul

Hi Paul,

1. awSets.init() and .destroy() does this job (hence the name awSets) so you no longer need your class at the application level; you just need whatever plain SET required in sficSets.Init() (for example see tutoSets.Init())
2. forms running in a private datasession only need to care about SETtings that are not scoped to the datasession; eg. SET DATE should not be included; you may need to add a parameter to yourClass.Init() to indicate a private datasession: in .destroy(), if private datasession, do not restore the current state of SETtings scoped to the datasession; for a complete list of SETtings that scope to the datasession or not, modify command abDev.prg > function aVFPsets()
3. you should add the property holding your settings object to .wcPropSaveNot: when saving and restoring state, FoxInCloud will continuously load and unload the object, execute its .Init() and Destroy() method, resulting in contradicting SETs
4. I would advise the following adaptation:

• as mentioned earlier, do the application-wide SETs in sficSets.Init()
• in form or members' methods where you need a specific SETting, use abSet()
• keep your settings object if you want to keep the ability to run a form in desktop mode using ctrl+E:

procedure init
…
if thisForm.wlLAN
  thisForm.prop = createObject('mySettings')
endif
…

3. would FiC really execute the init() and destroy() during a state change? By then, isn't it just a form property that happens to be an object and the object and its properties would be restored each time?

I'll need to continue using the object, or something else, in private datasessions for settings like set("database") which are scoped to the current datasession only.
Does ABSet() take care of restoring the original setting when the form is "closed" (or whatever actually happens in web mode)?

Paul

would FiC really execute the init() and destroy() during a state change? By then, isn't it just a form property that happens to be an object and the object and its properties would be restored each time?

Here is what happens in modify command abOOP.prg > function objectOfXML():

when restoring an object property from its XML representation, if the object instance still exists, FoxInCloud keeps the instance alive, reverts all properties to the class default value, then assign the properties whose value is different from class value.

As this process is recursive, object properties of object property follow the same logic.

In the end, when saving and restoring object properties, FoxInCloud does not execute .init() and .destroy().

However, if this setting object is instantiated at .Load() or initial .Init(), it will never change across users and thus it does makes no sense to save and restore it.

I'll need to continue using the object, or something else, in private datasessions for settings like set("database") which are scoped to the current datasession only.

YOU DON'T NEED TO SAVE AND RESTORE SUCH SETTING! by definition SETting that are scoped to the datasession can just be set in .Load() and that's it; eg. modify class ficFrm of ficSample method load

Does abSet() take care of restoring the original setting when the form is "closed" (or whatever actually happens in web mode)?

yes, this is the benefit of such class: SETting always gets restored at the end of the procedure, even if an error occurs.

local abDelete as abSet of abDev.prg
…
abDelete = abSet('deleted', 'off')
…
…
endproc && as VFP releases abDelete (standard behavior), abSet.destroy() executes

Yes, you are right that settings like that don't need to be restored when a private datasession closes; we have an existing framework though that does all sorts of automatic things within forms and I'm trying to minimise any refactoring I need to do.
I'll have to change the behaviour in this area.

Thanks
Paul

you can keep this settings object property unchanged; just make sure to add it to .wcPropSaveNot