03:17:49 AM
3HJ072H9O
1- Application-wide data that don't depend on user ID nor user's actions/events (e.g. set at application startup, like read from a .ini file ) should be stored in PUBLIC variables; can be stored in _Screen.properties but in this case FAS will uselessly save and restore data that won't ever change during the course of the application
2- Application-wide data that only depend on user ID (such as security profile) can be stored in either:
. PUBLIC variables and restored on each request through xxxProcess.wUserSet() or aw.vcx!awFrm.wUserSet()
. _Screen.properties and either restored on each request like described above, or saved by FAS (when _Screen.properties are actually saved by FAS)
Note: user session data can be stored in wConnect Session table through wwSession.set/get/SessionVar()
3- Application-wide data that depend on user's actions/events should be stored in _Screen.properties and FAS should save them.
[strange design IMHO as this kind of data can be passed between forms by form.Init(parameters) and RETURN in form.Unload(), which is much easier for debugging than PUBLIC variables or _Screen.properties]
Please let us know if you are in case 3 above, then we'll move up _Screen.properties save and restore up the roadmap.
So far we've never needed this feature in current FIC applications.
Ouch, It was your suggestion to use _screen to hand things from. Now I will have to change the controlsource for controls on about 250 forms. I changed from application objects to _screen to have session objects, I am not lookinjg forward to re-doing 250 forms again.
Anything used as a controlsource has to be saved.
So far, FAS does not save _screen properties
This needs be implemented in a future version
When restoring properties, like in a form refresh, FiC cannot tell the difference between:
_screen.osession.gdCMonDate1 and _screen.osession.gdCMonDate2 .
I instantiate two text boxes, each with one of the two above vars as a control source. In the click of a button I compare the values. If they are not valid, I display a message telling the user to re-enter. That is all. After that point, the refresh cannot tell the difference between those two and BOTH textboxes will display the same value.