View member feedback to this tip.
How annoying is it when a database owner wants a new entry in a dialog list and you have to open the database in Designer and perhaps even have to go through change procedures, testing, etc.? How nice would it be to give the owner the ability to manage dialog list entries without having to use multiple forms/views? Wouldn't it be nice to do this via only one form and one view?
Create a form and add three fields: Type, Value and Comment.
Create a view with the fields in this order (sort of first two columns). Add first doc as "Configuration, Configuration, Do Not Delete!"
Redesign form to make Type field a dialog list using the first field of the view as a lookup (@DBLookup) and returning the values from the second field. Add further entries as Configuration, PickListName.
Now comes the clever bit. Add more docs with PickListName as the Type and then the value you want to appear in your dialog list. Repeat as necessary and use the same @DBLookup to extract the dialog list values in multiple forms/fields.
This is very useful if you have lots of dialog lists and it's a new database where the users will almost certainly want to add more values. Access to add values can, of course, be easily restricted to the database owner/administrator.
MEMBER FEEDBACK TO THIS TIP
I think I follow this idea, but I believe that I've handled this issue in a much simpler manner, requiring one form, one view, and one data document. It works for me.
Form: Let's call it "Global Variables".
-- Contains one field for each dialog list (allowing multiple values) in the database.
-- Can have the fields in controlled sections if you need additional control over who edits what.
-- Also contains other constants/values that might need to be altered from time to time.
-- One very useful field is a flag for a debug mode. Many of my applications involve sending messages from user to user during the flow of a process. During testing, setting this flag can enable all sent messages to be routed to a common ID, thus not confusing the user population.
View: Let's call it "(Global Variables)".
-- Each column references one of the dialog list fields from the form.
Data document: There is only one; it's created when the database is first set up.
Usage: Wherever you have a dialog list, obtain the choices using @DBColumn to reference the globals view and the respective column of the field you want. To add a new dialog list, just add a new field to the global variables form, add the field to the view and reference it using @DBColumn. The user can then supply the values (actually, I guess there are really two views as a second one is provided to the administrative users to be able to access the global document and update the values while the hidden view is used by the forms). Most users will never know the form or views exist.
An additional plus is that in LotusScript all the field values can easily be obtained as needed from the first (and only) document in the globals view.
—Micky R.
Do you have comments on this tip? Let us know.
This tip was submitted to the SearchDomino.com tip exchange by member Dave Mills. Please let others know how useful it is via the rating scale at the end of the tip. Do you have a useful Notes/Domino tip or code to share? Submit it to our bimonthly tip contest and you could win a prize and a spot in our Hall of Fame.
