If your company is large enough that there will be a migration period where some users will still have Notes 5 while others have Notes 6, then you might think that you can't take advantage of any of the new 6 client features (like looping in formula language) until everyone has upgraded. Well, that depends on the design. There are certainly some things that you can "upgrade" (the reason why it's in quotes will become apparent soon) right away so your 6 users can get the latest features.

For example, let's say you have a form that works fine in 5, but there's a field that uses a monospaced font to simulate a table. You would like to convert that to a real table which you can do by showing pass through HTML in the ND6 client. There are a few ways to handle this, but the easiest is to create a Notes 6 version of the form. Then you just need a way to show Notes 5 uses the old version and Notes 6 users the new version. We do this through form formulas on the views. Checking the @Version function will tell you what version the user has. Notes 6 uses numbers higher than 184 (184 was Notes 6 Pre-release 1). So numbers higher than that can use the new form and other users can use the old form. Here's a typical form formula:

@If(@TextToNumber(@Version) >= 184; "My Form (ND6)"; "My Form")

Set up the two forms to have the same alias. Since they have the same alias, your view selection formulas won't need to change, and other code shouldn't need to change.

Once your users have all been upgraded, you can delete the R5 version of the form and remove the form formulas from the views. This path will end up being a bit easier than adding code to the existing form and trying to handle the different versions there. For one thing, you will have less testing to deal with - if you do it all in one form, you'll have to test your form in both 5 and 6 to make sure you didn't introduce any problems for your Notes 5 users. With form formulas, you leave your Notes 5 version alone and you only have to worry about testing with the 6 client.

Bonus Tip

OK, so now how do you make the HTML table in the ND6 client? Computed text can be set up to pass-through HTML, and forms can be set up to render pass-through HTML in the Notes client. We put an HTML comment before and after the computed text so it's easier to recognize. So, we have a line that is entirely pass-through HTML that looks like:

<!-- --><Computed Value><!-- -->

The computed text computes all the HTML for the table as one long string. It has the <TABLE> tags and everything. The Notes client will compute the text, then render that HTML in the client. So you have a "dynamic" HTML table. The reason why "dynamic" is in quotes is because the HTML will be generated only on document open - not on document refresh. So, if you change the content of the HTML table, you have to close and reopen the document. However, this is easy to do in LotusScript. Get a handle to the current document, get its UNID, save the changes, close the current document immediately, then reset the handle to the current document and reopen it. For example, here is a part of some code we have used:

Set uiDoc = ws.CurrentDocument
Call uiDoc.Save
Set currDoc = uiDoc.Document
unid = currDoc.UniversalID
' ... Make your changes here ...
Call currDoc.Save(True, True, True)
Call uiDoc.Reload
Call uiDoc.Save
Call uiDoc.Close(True) ' Parameter closes immediately
Set currDoc = Nothing ' Clear the variable so Notes will not cache it
Set currDoc = db.GetDocumentByUNID(unid) ' Reset the handle
Call ws.EditDocument(True, currDoc) ' Reopen the document

Note that some of the variables are left off, but hopefully you get the idea.