Easier way to pull form names?

Hello - We had a programmer who looks through a database and pulls forms based on their names. Is there another way to re-write that portion of the code so each time a new form is created we don’t have to try to remember to add it to her Case instance?

'=====>UPDATE THIS LIST IF A GUIDELINE FORM IS ADDED!!!

		Case "Academic", "Chapter", "Athletic", "Award", "Career Development", "Chair", _

		"Dean's Chair", "Department Head's Chair", "Destiny", "Enrichment", "Faculty Fellowship", _

		"General", "Graduate Fellowship", "Honors", "Lectureship", "Libraries Endowment", "OldGuidelines", _

	"Professorship","Program Support", "Renaissance", "Trustee", "Distinguished Graduate Fellowship"

		'these are the forms to extract from

Subject: Easier way to pull form names?

You can pull the names of all forms in the database from the NotesDatabase.Forms property. However, this might not help if you need to specify different case logic for a particular form, or you want work on an arbitrary subset of forms. If you are just selecting a subset of the available forms, I recommend just putting the list of names in a keyword document. Then at least you don’t have to modify the code each time, just to update the document.

Subject: Easier way to pull form names?

Without seeing the context of the Select statement, it is difficult to know what would work within your program. Are there other Case tests (other than Case Else)?

One idea is to have another computed field on each form such as FormType that could be set to “Guideline”, . If you could change the Case statement to Select Case FormType and have Case “Guideline”, that might work.

But if you need it to work within the structure of a Case statement that is looking at the Form field, that idea would not work.

Another method that would not require an additional field is to have a database profile document that has a multi-value field where you list the names of the Guideline forms. Then in your code you would test to see if the Form field value is one of the values in that profile field, and process accordingly.

This would work if you could use an If statement instead of the Select structure.

Subject: Easier way to pull form names?

Not sure what you mean by “Pull Form Name”??

The field Form has the Form used for each document.

Therefore, I’m guessing you mean “Form” in the more generic sense vs. Lotus Notes Design element?

Taking a shot at what you mean, I’ve set-up cross reference documents so the custodian of the DB can just add another Xref done whenever something new is updated.

For example, I have a field called Business Solution which is based upon the product. Clearly, anytime the company adds a product I don’t want to have to change the code.

So I created a form called Xref with a Product Field and a Business Solution Field.

Then on my form Busines Soluition has the following calculation:

FieldName := “Solution”;

Srv := XrefSrv;

Path := XrefPath;

OrgVal := @GetField(FieldName);

Case := “Business Solution”;

DefaultVal := DP_Material;

Key := @UpperCase(Case + DefaultVal);

ViewName := “luXref”;

Values := 2;

PromptTitle := "Select "+ Key;

PromptMsg := “Select from the following:”;

ErrMsg := (Key + " not found on the “):(ViewName + " view.”):(OrgVal);

List := @DbLookup( “”:“NoCache” ; (Srv: Path) ; ViewName ; Key ; Values );

@If( @IsError(List); DefaultVal; @Unique(@Trim(List)) )

I use this Xref form and view for other things, so part of the key is the word “Business Solution” you do NOT need this if you only have the one case.

Not sure if that helped any or if I misunderstood.

Subject: Easier way to pull form names?

My preference here would be to redesign the database so that there is only one “Guidelines” form, and the various specific designations are controlled by a DocumentType field (which is how things are done in the TeamRoom database). I really can’t see how there could be enough of a difference between the guideline types to warrant an entirely new form – the only thing that really needs to change from one to the other is a bit of text, which can be computed based on the document type (and controlled by a configuration document, Profile or otherwise) and perhaps a computed subform or two in case of “extreme” differences. That would REALLY simplify the Case statement, wouldn’t it?