Principal field invalidates RFC 5322 compliance

Due to lack of time, another post in ‘shorthand’:

Outgoing SMTP messages are rejected by ISP or Gateway appliance with error “Invalid sender address”

RFC 5322 requires a from field in the header of every email. Emails that were sent from LotusScript specifying an invalid entry for the Principal field caused Domino to create invalid message headers. The mandatory From field was missing.

When using Principal fields, ensure to use valid names. This are full names or abbreviated names as listed in the Domino Directory but not email addresses. Using email addresses in the principal field causes above issue even if the address is listed as an additional entry in the User Name field.

Type mismatch error caused by incorrect regional settings

Today was head scratching day again. Lotus Notes 8 was raising an error message that sounds so unusual for a Lotusscript developer:

Type mismatch in method CoerStrToNum: STRING found, double expected.

The only change to the environment has been the upgrade from Notes 7 to version 8. As it turns out, there are also a few notes about this message on Google, including a rather dubvious technote from IBM.

As it turns out, the source of the issue can be found in these two lines of code.

myDate$="17/01/2008 7:17"

Interstingly enough is the error message new to version 8 of Lotus Notes, obviously raised itself by the underlaying C++/Java code. All previous code streams, including the 8 debugger are raising the familar “type mismatch” error. This might create the impression that a regression bug has been introduced in Notes 8 – which is completely false.

Anyhow, who would have expected that the whole issue has been caused by a wrong regional setting on the underlaying operating system? In this case it has been set to US (American), with a date format of mm/dd/yyyy. As there isn’t a 17th month in a year the code fails.

I guess I would leave it open for discussion whether this has been an oversight by the developer, who couldn’t imagine that his/her code would ever been run in different region or a mistake by the persons setting up the laptop to not configure the (for New Zealand) proper date format dd/mm/yyyy.

Applying form formulas to document links

Since I first discovered the nature of document links I was always wondering about the purpose of each individual attribute. Why would I possibly need a view attribute when I just intended to link to a unique document within a specific database defined via the replicaid? Just wait and see what interesting thought IBM (or probably IRIS) has put into the definition of a document link and how they implemented it.

Imagine an application having different form formulas in different views. ViewA is having a form formula that opens the document with FormA, ViewB’s form formula is enforcing the document to be opened using FormB. If a document link is created and sent out to an user the document link created from within ViewA will open the document using FormA whereas the link created from within ViewB will open the document using FormB. Even when creating the document links after the document has been opened the view information is retained and contained within the document link. This is a pretty smart behaviour that totally makes sense. If UserA is sending out a link to UserB it is only reasonable that both are having the same results on the screen.

In order to fully understand this behaviour we need to look into the background design of a document link. As described above there are 6 attributes in the doclink element: document, anchor, view, database, server and description. In order to successfully link to any document within a database only the document element containing the universal ID of the document is required*. Each of the document links in above example did have another element defined, the universal ID of the view to be used when opening the document from a link. Having this additional information attached to the document link enforces the document to consider the form formula of the defined view when opening.

How does this apply to the day-to-day application design? Well, it depends. I guess it could be anything from not at all to massively! First of all it is worth mentioning that each linked document requires a view definition in order to determine whether an alternative form should be used or not. Wait, this sounds different to previous paragraph! Alright, the definition of the view can be done directly in including the universal ID of the view or indirectly by omitting this element. Omitting the view element forces the document link to evaluate the form formula (if existent) from the default view of the database. This is an important fact to note as each background function attaching a document link is checking for the existence of a default view during runtime prior to perfoming an action. This includes methods like NotesRichTextItem.AppendDocLink or the @MailSend function with [IncludeDocLink] option. Once called without a default view being defined within an application the error “Couldn’t get default View id for database” will be raised.

All the facts above are getting really important though when you start creating or manipulating document items using the NotesDXLImporter class. To come back to the subject of this post, you could indirectly apply a form formula to a document link in defining a hidden view, that doesn’t need to display any documents but defines a different form than the form that has been used to create a document. You could then utlise Domino XML (DXL) to send out a document link defining this special view to be used for the form definition. Unfortunately the view events of this hidden view are not triggered when using the document link. Although the alternative form could contain a form event to count access via link or run any special processing. The sky is the limit …

* Note that the Domino Document Type Definition (DTD) is solely defining the document element compulsory. This is true if the linked document resides within the same database. If the link is being sent out though it requires at least the database element to be defined as well.

Prepopulating rich text content for new documents

Since I have finished my last big administration project I am now back into Development for a short wile.

One requirement for an application I am currently building was the ability to prepopulate the content of a rich text field with true rich text content for new documents. ‘True’ rich text content in this context implies that the default value consisted of a number of tables and pre-formated text.

As the default content of the rich text element could be changing and the user want to have the ability to alter it without the need to challenge a Domino Designer (in this case a person doing design changes in Domino applications) I decided to store it in a profile document.

Responsible to move the content from the template to the new document is the Onload event of the form. The advantage of the solution provided below is, that the document itself does not have to be saved at any time. Hence the user can decide at any point in time to just close and cancel the creation of the document.

Please note that the name of the form (FSample) has to be set to the form field of the (in memory) document as the document itself has not been saved at this point of the time but is requested to be re-opened for editing two lines below.

Sub Onload(Source As Notesuidocument)
 Set s = New NotesSession
 Set db = s.CurrentDatabase
 Set uiws = New NotesUIWorkspace
 Set doc = source.Document
 Set docProfile = db.GetProfileDocument ("FProfile")
 If Not doc Is Nothing And Not docProfile Is Nothing Then
  If Not doc.HasItem(sItemName) And docProfile.HasItem (sItemName) Then
  Set rtitem1 = docProfile.GetFirstItem (sItemName)
  Call doc.CopyItem (rtitem1,sItemName)
  Call uiws.EditDocument(True, doc, , , , True)
  Delete source
  End If
 End If
End Sub