What I Learned About Rich Text This Week

I don't work with rich text alot, but I am aware of its eccentricities. I learned a few things this week and I thought I'd share them so as to save someone the time and frustration I endured. Starting out, I was at least aware of the whole issue with refreshing rich text in the UI, so this influenced my ideas of how I was going to approach my project.

For a Notes client app. I needed to control editing of a rich text field on a form. My first thought was to have a computed field just display the contents of the field and create a dialog box for authorized folks to edit the actual data. Although this is possible with some workarounds, the default nature of LotusScript dialog boxes is not rich text friendly. By default you can control the passing of field changes from your dialog box back into the underlying form, but not with rich text. The workarounds are to get rid of the default "OK" and "Cancel" buttons and build your own directly on your dialog box form so you can save your changes to the back end and do some script magic to make the changes appear on the underlying form. After working on the script magic and getting things to refresh, I found a show-stopping flaw in my approach. The biggest problem with this approach is that you don't have access to the rich text controls for adding any formatting to your text -- without that, what's the point? The bottom line is I abandoned the dialog box and opted to go with computed and editable fields and some show/hide formulas on the main form.

The first thing I ran into with this approach was the fact that a computed rich text field acts like a computed when composed field. The field gets set the first time it is displayed, but won't change if you make changes to the field it is computed to. Luckily Google is my friend and I found a way to make this approach work. Basically, I added a third computed text field with the formula FIELD myComputedRTF := @DeleteField; "" which blows the computed rich text field away every time the document is saved so that it can be recreated the next time it is opened.

Hope this saves someone the time and hassle learning this the hard way...

Cannot execute the specified command (ViewExpandAll)

I ran into another glitch in testing the Notes 8.5 client. When opening a couple views in a custom DB, I get the warning "Cannot execute the specified command." The LotusScript debugger wasn't able to help with the diagnosis (no LotusScript firing before the error appears). I then manually tried to follow the sequence of events and found the @Command ViewExpandAll in the PostOpen event of the views. I commented out the formula and that stopped the error.

Google isn't returning any hits to provide insight surrounding the problem. Having the view automatically expand isn't critical and we could live without it, but I'm curious if there's a workaround. Should I be reporting these problems to Lotus?

The peaceful coexistence of Java and .Net

Hopefully no one takes this the wrong way, but I just found it interesting that the Java group hosts its site using .Net technology.

(Then again, this Notes blog isn't hosted on Domino. Probably in both cases the reason why has a financial component.)

Not a sub or function

In my testing of custom Notes applications written for version 7 and prior, some applications throw the "Not a sub or function" error message in the R8.5 client. The errors aren't triggered when the LotusScript Debugger is turned on. This leads me to believe that subtle differences in the compiler versions are the culprit. I opened the application in the 8.5 Designer and ran Recompile All LotusScript from the Tools pull-down menu. This appears to have stopped the errors. The recompile had no adverse impact when going back and testing the application in a R7 client.