Ben Langhinrichs

Photograph of Ben Langhinrichs

E-mail address - Ben Langhinrichs






September, 2019
SMTWTFS
01 02 03 04 05 06 07
08 09 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30

Search the weblog





























Genii Weblog

Rocky's workaround

Thu 17 Jun 2004, 10:55 PM



by Ben Langhinrichs
No matter how much you love Lotus Notes (and I can work up quite a bit of enthusiasm), you have to admit that a good Lotus Notes developer better be ready and willing to workaround a few of the, shall we say, "oddities" in the software.  I have worked around a number of "features" myself, but I am not always the best person for this.  I have met a few pros in my day, and Rocky Oliver has to be one of them.  He is a wizard with formula language and a virtuoso with LotusScript, as many who have seen him speak can attest, but above all, he has a knack for solving problems with whatever works, even if it isn't the obvious.

The problem
Anyway, Rocky called me today because he was experiencing a problem with an application using our Midas Rich Text LSX, and he thought it might be something wrong with Midas.  Fortunately, it was not.  Unfortunately, it was a basic problem with Lotus Notes, and I couldn't whip up a fix for that.  The problem was that he wanted an uneditable rich text field, but when he made a computed rich text field, he lost the font and the table, but still had text attributes and text.  Sigh!  I have long hated this bug.  It is also a bit unpredictable, looking right at one point, then looking wrong again when the document is edited and saved again.

"So", Rocky said, "what can I do to work around this?"

My proposed solution
Now, with other people, I might just tell them to avoid the scenario, but I am not about to say that to Rocky.  As a friend, co- Penumbra member, and guru (see above), I thought he might be able to handle something a bit more sophisticated, and perhaps help me develop an idea I'd had that might work.  I suggested that he create a controlled access section, put the editable rich text field inside the section and make sure the person editing didn't have access.  Voila!  Uneditable rich text.

Problems with my proposed solution
So, I sent Rocky an e-mail later on, and asked how it was going.  He wrote back
It technically worked, but it has this annoying thing where there is always some "artifact" on the page where the section is clickable, even if it is expanded and the title is hidden when expanded. Plus, if the user clicks this "artifact" (like a thick little dash), then it will collapse the section. I added a title that is faint that tells the user to click here to display the table, but it still feels a bit kludgy. If I could find a better solution I would use it, but for now it does accomplish what I want.

Rocky's workaround
I must tell you, I grinned at this, because I knew Rocky would not allow some annoying artifact to muddy up his application.  Sure enough, fourteen minutes later, he wrote again
OK, I got rid of the controlled access section, and switched to an editable RT field, not showing field delimiters, that has a uidoc.gotoprevField call in the Entering event. This basically gives me a RT item that can't be edited.
And he is right.  There may be something wrong with this workaround, but I haven't found it yet.  For years, I have hated this bug but never desparately needed an answer.  Rocky needed an answer, and figured something out in an afternoon.

Copyright © 2004 Genii Software Ltd.

What has been said:


172.1. Stan Rogers
(06/18/2004 01:12 PM)

There is one small potential problem, and that's that it will muck up tabbing if it always sends the user to the previous field. I hate to second-guess The Rock, but I'd have used GotoNextField (assuming I was clever enough to blow focus in the Entering event in the first place, which I isn't).


172.2. Ben Langhinrichs
(06/18/2004 01:27 PM)

Actually, I was thinking about that, and if I create a sample db showing this workaround, I think I'll add an Entering even in the field immediately prior to and immediately after the rich text field, so that if you go from the one before it will go to the one after and vice-versa. The advantage is that tabbing will work seamlessly, and people will still seem to "slide off" the rich text field. I haven't tried it, but it seems like it would work.

Another issue I don't know about is tabbed tables or sections in the rich text. Could you still switch tabs or open the section? I don't know.


172.3. Matthias TMC
(19.06.2004 13:48)

I just galloped through this blog entry:

I've had the same problems when trying to hide rich text.

I used also the entering event of the rt-field (.... uidoc.GoToField...) workaround so far (incl. turning of the field delimiters). I always specified the field where the cursor should go to....

I've never had troubles so far with this workaround (but remorse).

BTW, I found out some days ago, that we do not have the possibility in text fields (not RTF) to use "paragraphs". OK, you can define paragraphs with the ruler in the form (by putting the cursor in the line where the field is), but if you use Chr(13) or in the textfield, no new paragraph starts in the text field - the cursor appears in the position of the last paragraph.

IMO this is a bug - or it is just not supported when using simple text fields.


172.4. Tomasz Frydryk
(2004-09-15 03:35)

Nice workaround. Tricky.

But there is a little other problem, I am facing with. My TRField is the only one field on tab. So in Edit Mode I can't open this tab. Do you have any idea what to do?


172.5. Barbara White
(09/27/2004 12:05 PM)

I was tearing my hair out trying to find a solution for this that wasn't too ugly. After browsing Notes.net & somehow ending up here.... the perfect solution! You're bookmarked as my first resource from now on. Thanks!


172.6. Jennifer Cohen
(10/14/2004 01:19 PM)

Fabulous solution!