This hasn't come up in a while, but someone wanted to validate a rich text field in a recent project. There are a couple ways to do it, and it depends on what you are trying to validate - text and/or other items like attachments or links. Here, we talk about some ways to validate a rich text field.

The first way to validate a rich text field is to check to see if there is anything in the field. This means that the user could put in text, an attachment, a database/view/document link, even a single space. This check is done in the query save event on the form using LotusScript.

Sub Querysave(Source As Notesuidocument, Continue As Variant)
   Call Source.GotoField("Body")
   On Error Resume Next
   Call Source.SelectAll
   Call Source.DeselectAll
   On Error Goto 0
   If Err <> 0 Then
      Err = 0
      Msgbox "Please enter some text into the body.", 16, "Field Contains Incorrect Value"
      Continue = False
      Exit Sub
   End If
End Sub

This code works by going to the field ("Body" in our example) and then attempting to select and deselect all the contents of the rich text field. Those statements will cause an error ("Document command is not available") if the field is empty. So we trap for the error, and if it occurs clear out the error handler and give the user an error message and don't allow the document to be saved by setting Continue to False.

Personally, I don't like the above method for two reasons. First, there is UI action going on. If the form is a long form and the user is at the top and the body is at the bottom, the Souce.GotoField statement will jump the user's screen down to the rich text field. You can save the current field name (Souce.CurrentField) and jump the user back to that field when finished, but the jumping will still happen. Furthermore, the entire rich text field will be selected and deselected. If the user has typed in a few paragraphs, they will see the flash of that selecting/deselecting process. That can be unnerving to users ("did they do something to my text?").

Another method used for validating rich text content is to use validation in a hidden field. Rich Text fields don't have the Input Validation event, so you can't directly validate the field. But you can set up another field to do the validation. The field should be physically below the rich text field (because forms are validated top to bottom, left to right) and it can be hidden. (In fact, I recommend hiding the field). The field must be editable (that's the only way to get the validation event to appear). Beyond that, it can be any kind of field (I generally use text or number) and the rest of the content doesn't matter (I leave the default value alone and don't have anything in the input translation).

In the validation, it all depends on what you want to validate. First, let's say that the user has to enter in some text. And it has to be legitimate text - spaces or new lines won't cut it. (Note that a single space in the rich text field would pass the validation above). This input validation would trap for a rich text field with no text:

@If(@Trim(@Abstract([TextOnly]; 100; ""; "Body")) = ""; @Failure("Please enter some text into the body."); @Success)

If you're not familiar with @Abstract then you should look it up in designer help. We're pulling out the first 100 text characters from the field called Body and then trimming it to remove spaces. If we're left with an empty string, then there is no text in the rich text field.

But what if the user can put in an attachment and no text? You can easily add a check to the start of the validation to see if the user added an attachment.

@If(@Attachments != 0; @Success; @Trim(@Abstract([TextOnly]; 100; ""; "Body")) = ""; @Failure("Please enter some text into the body."); @Success)

Please note that @Attachments checks for the presence of attachments on the document, not necessarily the field in question. If you have multiple rich text fields, then the validation above may backfire because they could have put an attachment in another rich text field, different from the one you are validating.

What's the difference between the methods? In the first one, anything in the rich text field will validate. Even a single space. And there's the "interference" in the user interface that I don't particularly like. In the second one, validation will only happen if there is one or more legitimate characters - no spaces, tabs, or new lines will be allowed. In the third one, validation will happen if there are legitimate characters or if there's an attachment somewhere on the document.

My personal preference is to use the second method. If the user is putting in a link or an attachment or something besides text, they almost always add a couple of words to indicate what else they added to the field, and those added words will cause the validation to pass.