Manage Learn to apply best practices and optimize your operations.

Validating rich text

Validating rich text

From "Rich text programmability for Notes R5 applications" by Andre Guirard, who works from Lotus Development's ISV Technical Consulting group, which originally appeared in the May/June 2000 edition of The View


Notes developers have long had to work around the problem that, in Notes, there is no way to make sure that the user enters a value in a rich text field before saving a document. There are workarounds for specific kinds of validations, but until R5, there hasn't been a general-purpose way to validate rich text field contents.

With R5, it's possible to write a Querysave event that reads the current value of the rich text field. To do this, you have to refresh the form using the NotesUIDocument.Refresh method with an argument of True, as the code below does. This code, created as an example, doesn't actually do any validation; it just displays the text it reads from the rich text field.

Sub Querysave(Source As Notesuidocument, Continue As Variant)
	   Dim ws As New notesuiworkspace
	   Dim uidoc As notesuidocument
	   Dim doc As NotesDocument
	   Dim rtf As Variant
	   Set uidoc = ws.CurrentDocument
	   uidoc.refresh True
	   Set doc = uidoc.Document
	   Set rtf = doc.GetFirstItem("Body")
	   Messagebox debugstr(rtf.text)
End Sub

The debugstr function in this code takes any value and returns a text description of it in a message box. It's not part of the LotusScript language; it's a function the author wrote that can be pasted in whenever one needs to display a value for debugging purposes.

You can try this yourself in the sample database available at The View's Web site:

Select Create-Validate Rich Text. Enter some values in the table that opens in the Validate Rich Text document.

When you use the Text property or the GetFormattedText method of a NotesRichTextItem, tables are presented as columns of text separated by tabs. So there's a "tab" character (in LotusScript, Chr$(9)) between each column, and the "newline" sequence, carriage return and line feed (Chr$(13) and Chr$(10)), at the end of each row.

This can get ambiguous if the person editing the document enters tabs or newlines in the table cells. If you were trying to validate the table contents and you looked for the "newline" sequence to spot the end of a row, then "20 30" would look like two different rows to you. So you might not be able to tell exactly how the table is formatted. But for validation purposes, you don't care -- just reject any input that doesn't match what you expect.

Dig Deeper on Domino Resources - Part 5



  • Favorite iSeries cheat sheets

    Here you'll find a collection of valuable cheat sheets gathered from across the iSeries/ community. These cheat ...

  • HTML cheat sheet

    This is a really cool cheat sheet if you're looking to learn more about HTML. You'll find just about everything you every wanted ...

  • Carol Woodbury: Security

    Carol Woodbury