Add rows at a table defined in the design when editing the document

Dear friends,

In a form, I defined a table in the design. This table has 2 rows, 1 for the column titles, and 1 for the content.

What I would like is that when a user creates/edits a document from his notes client, he has the possibility to add as many rows as required in this table.

I found one or two commands, such as @Command( [EditTableInsertRowColumn] ), but these work only when the table has been created by the user while editing the document.

Is there a possibility to have a table defined in the designer and then modified during the editing ?

Thanks in advance,

Denis.

Subject: Add rows at a table defined in the design when editing the document

The problem is that not only do you need to add rows, you need to add UNIQUE fields to hold the data than the user then enters into those rows.

There is no native way in Notes to do this sort of stuff, short of creating x rows and fields on the form, and then unhiding them as needed.

Now if the data that the user is entering does not need to be accessed (in a view for example) then you can do the following…

Create a new form with a title and a Rich Text Field (e.g. RTF_Form)

Create a view of these forms, with the title as the first sorted column.

Create a document with this new form, give it a title, and put your 2 row table into the RTF.

Replace the table in your original form with a Computed Rich Text Field that does a DBLookup on your new view, based on the title, and returns the RTF.

When a user creates a new document, the 2 row table is copied from your document above.

The user can add rows using the Tab key when at the bottom of the table.

Because all of the rows and data are in a single RTF, you cannot access that data programmably.

Subject: Not true…

This has been discussed many times in these forums. They take some work on your part to create but are an extremely viable solution. Basically a single field for each column, allow multiple values with new line as the seperator.

Subject: I use a “dynamic table” with buttons beneath it

that add additional rows through a popup dialog box. It is rather intensive and lengthy but sounds like what you are looking for. I use this button/dialogbox setup for what I call “Transmittal Forms” … I have as you do a table with two rows, top row column name, second row are multivalue fields, new line separator. If you are interested in this somewhat complicated, lengthy procedure but need it for multiple forms, it is well worth setting up and works very well. HTH. I’ll check back to see if you want it. I had posted this a long time back for some reason today I cannot find any of my old posts, just those within the last week. Cathy

Subject: RE: Not true…

True, but that does not actually create new rows in the table - but may indeed address the root problem.

Subject: Add rows at a table defined in the design when editing the document

There is no native way. You have three basic approaches for this.

The first, and most traditional, approach is to create as many rows as the users might use and hide them with hide-when formulas which get unhidden when you “add a row”. It can be slow, and it is difficult to know how many rows to include, but it is doable. In 6.5, you likely won’t have the problems of shifting hide-when formulas in tables that plagued earlier Notes versions.

The second approach is to store the form in the document and use a third party product such as our Midas Rich Text LSX to add rows as necessary. We have a sample which shows how to do this, and you can have as few or as many rows as you need. Look for the Design Demo sample db on our Midas samples page (but you will need the eval license to try it out)

The third approach is to use multi-value fields and simulate rows. This can be useful in some scenarios, but it has major limitations both because a value may wrap and throw all rows off, and because you can’t have true fields for each value, which prevents any field formulas and such from working.

Subject: RE: Add rows at a table defined in the design when editing the document

Another option, which may not be optimal is to create mini-response documents and display them in an embedded view.

Subject: *Good point. Thanks for adding that.