Reposting about [NoPersist] option for @set / getprofilefield

I am missing something embarassingly obvious …

I am trying to make use of this undocumented feature using two forms:

Form1 has an action with

T := “xxxxxxxxxx”;

@SetProfileField([NoPersist];“T”;@UserName)

and Form2 has an editable field defaulting to

@GetProfileField([NoPersist];“T”;@UserName)

but nothing appears, the field is blank.

I replaced the set in Form1 with

@SetProfileField([NoPersist];“T”;“xxxxxxxx”;@UserName)

with no success (and no error …)

I searched the forum and it looks I am the only who ever had a problem with this.

thank you

Subject: Well, let me guess (since it is undocumented). [NoPersist] hmmm…

that implies to me that the profile would not be saved, therfore when the form/agent/script that called it goes out of scope (i.e. you load a new form) the profile variables are deleted from memory.

Subject: RE: Well, let me guess (since it is undocumented). [NoPersist] hmmm…

I tried this option because I read here http://www-10.lotus.com/ldd/nd6forum.nsf/55c38d716d632d9b8525689b005ba1c0/be277d680c9dee2685256cc5007adf44?OpenDocument

that “… it can be used to pass information from one window to another (or frame to frame, …) …”

but I had no success.

I would be very nice to have, particularly if @setprofiledoc([NoPersist]) would work with readers authority in ACL instead of author

Subject: Well following the thread 2 posts down:

Posted by William S Andreas on 11.Feb.03 at 04:02 PM using a Web browser
Category: Notes ClientRelease: 6.0Platform: All Platforms

The information is stored in the client cache so it can’t be shared through the server cache. It’s also (currently) restricted so that it can only be seen by docs/pages created from the same form. The latter restriction is likely to be lifted once we verify there aren’t any security holes if we lift the restriction.

Subject: RE: Well following the thread 2 posts down:

Thank you,I did not really understand that.

So it looks presently of limited use.

Thank you again