1. wUserSet located in xxxProcess of xxxServer is ALWAYS called by AJAX BEFORE any other code is processed.
2. wUserSet located in awFrm is then called by AJAX BEFORE any other code is processed.
3. Form code of interest is run.
4. wUserGet located in awFrm is then called by AJAX AFTER all code was executed. If wUserGet returns a different User it is stored as the new User? -- not sure...
5. wUserGet located in xxxProcess of xxxServer is called by AJAX as the final call. If wUserGet returns a different User it is stored as the new User? -- again not sure...
I have gone through several version changes, 1.2 to current, and I think I have been confused. Let's see if I have figured it out.
The example of xxxProcess.wUserSet has alway been:
PROTECTED PROCEDURE wUserSet
LPARAMETERS twUser, tlTemp_Screen.AddProperty('myUserID', m.twUser)
_Screen.AddProperty('myUserRights', myUserRights(m.twUser))RETURN DoDefault(mtwUser, m.tlTemp)
ENDPROC
I have somewhat paraphrased the above sample code. It's not difficult to understand, I just could not understand why it was called so frequently. You see, I am again confusing versions of FIC.
Historically, FIC did NOT store Public vars and _Screen values. wUserSet is so named because each call from AJAX recreates the environment and since FIC did not retain _Screen, it was necessary to restore the _Screen values on every AJAX call and in this case "re"Set the User. This function name now makes complete sense.
Version 2.0 has brought a change, by setting lAppUserEnvSave = .T., Public vars and _Screen values are retained by FIC. I am supposing wUserSet in this case would need to become something like:
PROTECTED PROCEDURE wUserSet
LPARAMETERS twUser, tlTempIF EMPTY(_Screen.myUserID) && Store values on the very first call
_Screen.AddProperty('myUserID', m.twUser)
_Screen.AddProperty('myUserRights', myUserRights(m.twUser))ELSE && Values already stored
* Set something that may need changing...
ENDIF* Apply the values stored in _Screen, if required...
RETURN DoDefault(mtwUser, m.tlTemp)ENDPROC
FIC is now responsible for maintaining these properties.
Now, the choice becomes whether to use lAppUserEnvSave = .T. I believe the answer for me is obvious as I have to get permissions from an LDAP server and performance is an issue. However, what is the performance "hit" with lAppUserEnvSave = .T. in general? It appears as long as there are not a large number of variables, both approaches require some processing time and might be close to equal. Am I missing a potential performance issue?
I know have several embedded questions, but mostly i want to confirm my understanding. Hopefully this can help someone else in the same situation.
TIA - James
Re: wUserSet and _Screen FoxInCloud Support - Thierry N.
James Patterson
Mar 27, 2015 @ 07:25am
The process you describe is right.
1/ You can measure the perf impact of xxxServer.lAppUserEnvSave quite simply:
use Temp\_<userID>__<xxx>_APPENV
sum nSaveMS + nRestMS for cScope = 'S' && Save and restore time for _screen properties (ms)
2/ I agree with you about the .wUserSet() code samples - we'll explain that restoring _screen properties is useless using
xxxServer.lAppUserEnvSave and !empty(xxxServer._ScreenPropertiesSave)
Hope this answers your questions.
After setting numerous breakpoints and re-reading the posts here, I think I understand wUserSet and wUserGet. Now let's test that assumption!
1. wUserSet located in xxxProcess of xxxServer is ALWAYS called by AJAX BEFORE any other code is processed.
2. wUserSet located in awFrm is then called by AJAX BEFORE any other code is processed.
3. Form code of interest is run.
4. wUserGet located in awFrm is then called by AJAX AFTER all code was executed. If wUserGet returns a different User it is stored as the new User? -- not sure...
5. wUserGet located in xxxProcess of xxxServer is called by AJAX as the final call. If wUserGet returns a different User it is stored as the new User? -- again not sure...
I have gone through several version changes, 1.2 to current, and I think I have been confused. Let's see if I have figured it out.
The example of xxxProcess.wUserSet has alway been:
PROTECTED PROCEDURE wUserSet
LPARAMETERS twUser, tlTemp_Screen.AddProperty('myUserID', m.twUser)
_Screen.AddProperty('myUserRights', myUserRights(m.twUser))RETURN DoDefault(mtwUser, m.tlTemp)
ENDPROC
I have somewhat paraphrased the above sample code. It's not difficult to understand, I just could not understand why it was called so frequently. You see, I am again confusing versions of FIC.
Historically, FIC did NOT store Public vars and _Screen values. wUserSet is so named because each call from AJAX recreates the environment and since FIC did not retain _Screen, it was necessary to restore the _Screen values on every AJAX call and in this case "re"Set the User. This function name now makes complete sense.
Version 2.0 has brought a change, by setting lAppUserEnvSave = .T., Public vars and _Screen values are retained by FIC. I am supposing wUserSet in this case would need to become something like:
PROTECTED PROCEDURE wUserSet
LPARAMETERS twUser, tlTempIF EMPTY(_Screen.myUserID) && Store values on the very first call
_Screen.AddProperty('myUserID', m.twUser)
_Screen.AddProperty('myUserRights', myUserRights(m.twUser))ELSE && Values already stored
* Set something that may need changing...
ENDIF* Apply the values stored in _Screen, if required...
RETURN DoDefault(mtwUser, m.tlTemp)ENDPROC
FIC is now responsible for maintaining these properties.
Now, the choice becomes whether to use lAppUserEnvSave = .T. I believe the answer for me is obvious as I have to get permissions from an LDAP server and performance is an issue. However, what is the performance "hit" with lAppUserEnvSave = .T. in general? It appears as long as there are not a large number of variables, both approaches require some processing time and might be close to equal. Am I missing a potential performance issue?
I know have several embedded questions, but mostly i want to confirm my understanding. Hopefully this can help someone else in the same situation.
TIA - James
Hi James,
The process you describe is right.
1/ You can measure the perf impact of xxxServer.lAppUserEnvSave quite simply:
use Temp\_<userID>__<xxx>_APPENV
sum nSaveMS + nRestMS for cScope = 'S' && Save and restore time for _screen properties (ms)
2/ I agree with you about the .wUserSet() code samples - we'll explain that restoring _screen properties is useless using
xxxServer.lAppUserEnvSave and !empty(xxxServer._ScreenPropertiesSave)
Hope this answers your questions.
After setting numerous breakpoints and re-reading the posts here, I think I understand wUserSet and wUserGet. Now let's test that assumption!
1. wUserSet located in xxxProcess of xxxServer is ALWAYS called by AJAX BEFORE any other code is processed.
2. wUserSet located in awFrm is then called by AJAX BEFORE any other code is processed.
3. Form code of interest is run.
4. wUserGet located in awFrm is then called by AJAX AFTER all code was executed. If wUserGet returns a different User it is stored as the new User? -- not sure...
5. wUserGet located in xxxProcess of xxxServer is called by AJAX as the final call. If wUserGet returns a different User it is stored as the new User? -- again not sure...
I have gone through several version changes, 1.2 to current, and I think I have been confused. Let's see if I have figured it out.
The example of xxxProcess.wUserSet has alway been:
PROTECTED PROCEDURE wUserSet
LPARAMETERS twUser, tlTemp_Screen.AddProperty('myUserID', m.twUser)
_Screen.AddProperty('myUserRights', myUserRights(m.twUser))RETURN DoDefault(mtwUser, m.tlTemp)
ENDPROC
I have somewhat paraphrased the above sample code. It's not difficult to understand, I just could not understand why it was called so frequently. You see, I am again confusing versions of FIC.
Historically, FIC did NOT store Public vars and _Screen values. wUserSet is so named because each call from AJAX recreates the environment and since FIC did not retain _Screen, it was necessary to restore the _Screen values on every AJAX call and in this case "re"Set the User. This function name now makes complete sense.
Version 2.0 has brought a change, by setting lAppUserEnvSave = .T., Public vars and _Screen values are retained by FIC. I am supposing wUserSet in this case would need to become something like:
PROTECTED PROCEDURE wUserSet
LPARAMETERS twUser, tlTempIF EMPTY(_Screen.myUserID) && Store values on the very first call
_Screen.AddProperty('myUserID', m.twUser)
_Screen.AddProperty('myUserRights', myUserRights(m.twUser))ELSE && Values already stored
* Set something that may need changing...
ENDIF* Apply the values stored in _Screen, if required...
RETURN DoDefault(mtwUser, m.tlTemp)ENDPROC
FIC is now responsible for maintaining these properties.
Now, the choice becomes whether to use lAppUserEnvSave = .T. I believe the answer for me is obvious as I have to get permissions from an LDAP server and performance is an issue. However, what is the performance "hit" with lAppUserEnvSave = .T. in general? It appears as long as there are not a large number of variables, both approaches require some processing time and might be close to equal. Am I missing a potential performance issue?
I know have several embedded questions, but mostly i want to confirm my understanding. Hopefully this can help someone else in the same situation.
TIA - James