Rich Text Fields default value

[fishkake]

Hello again!

Is it possible to put a table in a Rich Text Field's "Default Value" event? Is there perhaps a way to build a table using the formula language?

The only way I can think of is to build a profile document, put the table in there and then paste it in the RTF with the PostOpen event of the form, but this is a lot of work, and I'm sure its not very efficient in terms of processing.

 

[ABOzIT]

I don't know of any way of doing this. Can you elaborate a bit more on your intentions. If we know some more detail on why you need to do this we may be able to explore other ideas.

Cheers!

 

[fishkake]

What I want is a table. I have a rich text field at the bottom of my form, for "Actions taken" (its a Sales Trip Report form). This table must have three columns (What, Who and When) but a variable number of rows, depending on the trip!

When a table exists in a Rich Text field, the users can use "tab" to change cells, and after the last cell the tab key will create a new row, which is ideal! Without this table, I will need to create a table in Designer, put 30ish fields in it, and hide each row with a Hide When formula so that it appears right; this is obviously not ideal from a performance perspective, and not ideal from a development perspective!

Is that a little clearer? I was hoping there was a way to build a table using formula, such that I could put this in the "Default Value" event and all would look right. As I mentioned, I could paste it from a profile document in the PostOpen event or something, but I'd rather not inflate my database with one of those - this was supposed to be a 5 minute job, with the Doc Library template and one or two tiny changes!!

 

[pmonett]

In R6 you have the AppendTable method to work with NotesRichTextItems.
Unfortunately, working inside an RT item from code is quite difficult (its meant to be used by the user, not the designer !), and you will not be able to append rows to the table, although you can create another table.

I would suggest reviewing the requirements and using the Embedded Views functionality. In this way, when the user wants to "add a line", you could actually have him create a new document (of a special type). This new "line" would then be displayed in the Embedded View, creating a table-like functionality. Two advantages : no need to create and maintain a 30-row table in design (I know the pain !) and a much easier management of the existing "rows", since they can be deleted via simple click and Del key manipulation.

Of course, these rows are certainly destined to create a meaningful total somewhere, and that's where you will need to code some more in order to go into the view and get the total to put into the document. That is a bit tricky to get it done without bombing the response times of the client, but it is entirely possible.

Pascal.

 

[fishkake]

Hello again Pascal - if you help me any more I'll be obliged to give you part of my salary!!

This has finally highlighted the unusual behaviour of RT fields - I have been warned of such, but never experienced it myself. I have appended the table to the RT field, but unfortunately this means that the document has to be closed and then opened again. Also, it seems to require me to use a notesdocument.save command - if this is in the QueryOpen event, it will result in the automatic creation of documents, even if a user closes without saving, which is obviously not ideal.

Any idea how I can use the AppendTable method when a document opens, and then have the (UI) document show the contents of this field? I tried notesuidocument.refresh, but it didn't help.

No totalling or anything like that is required, the table is simply to look as follows:

What Who When
Something A. Person 02/05/04
Another thing G. Neric 05/05/04
Something else O. Minous 12/05/04

etc... Its just a pretty way to show text, there's no programming to be done with this table.

 

[pmonett]

Um, right, that it an additional restriction I forgot to mention : code modifications in an RT field require doc save and reopen. There is nothing you can do to avoid this.

You might want to look into using multi-value text fields set to display values with a new line. This is just about the only option left to implement. The advantage is that you can have only one field per column. The disadvantage is that, if you really want to control display correctly, the user cannot be allowed to enter values directly into the fields - you have to give him a popup into which he can make his addition/change, then deal with inserting it in the lists in the correct format. Which also means coding for removal of lines, partial editions and all such variations.

A bit tricky to do in formula language, but its been done. Hundreds of times actually, so you should be able to find code examples to download.

As for the percentage, any time, buddy, any time ;-).

Pascal.

 

[fishkake]

Um, right, that it an additional restriction I forgot to mention : code modifications in an RT field require doc save and reopen. There is nothing you can do to avoid this.

GOD DAMN IT!!!

I'll do it with copy-and-paste, and a profile document. This isn't ideal, but it does mean that I can create a table in the Notes client, in an RT field in the profile document, and then have it paste into the RT field on the document when the user presses a button.

This was supposed to be a five minute job. Why is there no such thing?