1. The dialog list field should be set to allow values not in list.
2. Create a hidden field on the form that uses the same @GetProfileField formula as the dialog list.
3. On querysave, test value of dialog against values in hidden field with this code:
FIELD fileType:=fileType;
FIELD fileTypeOld:=fileTypeOld;
@If(@IsNotMember(fileType; fileTypeOld); @SetProfileField("choicesForm"; "fileTypeChoices"; fileTypeOld : fileType); @Return("") )
2. Create a hidden field on the form that uses the same @GetProfileField formula as the dialog list.
3. On querysave, test value of dialog against values in hidden field with this code:
FIELD fileType:=fileType;
FIELD fileTypeOld:=fileTypeOld;
@If(@IsNotMember(fileType; fileTypeOld); @SetProfileField("choicesForm"; "fileTypeChoices"; fileTypeOld : fileType); @Return("") )
Show-n-tell+thursday
5 comments:
Thanks... since you've already taken care of that, I'm looking for a new project :o)
Isn't profile document caching a problem?
If two people both have the database open and add values one of their values would be lost.
You could probably get around this by accessing the profile document using @GetDocField/@SetDocField instead, and store the UNID in a field on the profile.
Michael, we use document locking to prevent multiple people from changing the profile at the same time. But we haven't run into any problems yet; even "regular" users have limited access so there are only a handful who are allowed to make any changes. Obviously if there were multiple replicas with wide-range access it might be a bigger issue. In that case, instead of storing field values on the profile, we'd probably just use an Allow Values Not In List, and have a lookup view that contains all documents with values in the dialog field. Then the formula for the dialog choices would be an @Unique(@DBColumn) lookup to that view.
Esther, I wasn't thinking about locking or replicas.
If you access a profile document then it is cached on your PC until you close the database. You won't see any changes that other people make while you have the database open.
Try this to duplicate the problem:
Open the form on two PC's. Now each PC has the profile document cached.
Now add a new value to the list on the 1st PC. I added "123".
Add a different new value on the 2nd PC. I added "456".
Now close the database on both PC's and reopen it. "456" has been added to the profile document, but "123" has not.
I had this problem when I first started using Notes and tried to use a profile document for storing a sequential reference number. I ended up just using a normal document instead.
For an alternative solution to Profile documents and @Environment function see my article about DigestSearch:
http://www-128.ibm.com/developerworks/lotus/library/digestsearch/
It solves problems with cached values, specially for multi-users, but is somewhat more difficult to implement.
Post a Comment