Rich text lite, embedded objects, lotusscript and the fieldOffset

HCL Domino Domino Forum
1

Hi folks,

I’m an optimist. This is usually a good thing, but it means that every now and then my fervent hopes are dashed by reality. This is one such occasion…

I wanted to use Rich Text Lite fields to allow my users to attach a picture file into a form without having to know how to attach an object. They look very good, and work very well in the notes client. Thumbs up there!

However, I thought I would do some further stuff with LotusScript, and here’s what I found out. When you get a handle to the document, or the rich text item in a variant, you will find the following little quirks:

For embedded objects in a rich text lite field - doc.HasEmbedded=False, believe it or not. doc.EmbeddedObjects is nothing, which I guess makes sense given the above. item.EmbeddedObjects is nothing. Nothing! You’re kidding, right?

If you embed the same file into a rich text field, you get doc.HasEmbedded=True, and the EmbeddedObjects arrays in both the document and the field are as they should be.

Is this a bug, or should I just give up and return to my old cynical belief that embedded objects are evil and will never be any use at all?

Speaking of which, another thing I would like to do here is open the object with a URL. Sounds easy enough, right? Wrong! You need to know the fieldOffset part of the URL, which is of course a ridiculously obscure property that is highly shrouded in mystery and to the best of my knowledge, impossible to find out without resorting to arcane arts and demon worship. Bummer!

In any case, I’ll take any friendly suggestions offered, and I promise to stay optimistic about the URL syntax being a bit more useful in the next version of Domino.

-Brendan

2

Subject: *They aren’t embedded. Embedded objects are attached, these are imported, if I understand you correctly.

3

Subject: Re: They aren’t embedded. Embedded objects are attached, these are imported, if I understand you correctly.

Hi Ben,

Imported? You’re right, the option I’m giving them in the rtl field is the ‘Picture’ one, and I guess this equates to importing a picture file.

However the interesting thing is that if I open it in a browser, the img tag gives me -

img src=…753f/rtlfield/0.8A?OpenElement& FieldElemFormat=jpg"

This suggests to me that domino treats it a little like an embedded object, and I had at least some right to be hopeful that I could get a handle to it. Would have been very handy and a much nicer interface.

In any case, I will admit that further investigation tells me that the only way to get to the point where it is truly an embedded object is to allow the RTL field to give the users the option for ‘OLE Object’. This then gives them the slightly ugly and confusing dialog box that I was trying to get away from in the first place.

Any ideas on the fieldOffset?

4

Subject: RE: Re: They aren’t embedded. Embedded objects are attached, these are imported, if I understand you correctly.

Unfortunately, I know way too much about the offset and all. Here is a bit of info. When you see rtlfield/0.8A, the rtfield is the fieldname, the 0. is which item of the rich text field (because rich text fields can be multiple items with the same name) starting with 0, and the 8A is the hex offset into that item of the appropriate CD record, whether it be a bitmap header or image header (for JPEG and GIF native files).

Does any of this help you? Well, not much. It is actually possible to traverse the CD records from script calling the C API, but I find it tends to lead people down a path they eventually wish they had not taken, so I’ll leave it to Rod or someone to post that sort of code.

5

Subject: RE: Re: They aren’t embedded. Embedded objects are attached, these are imported, if I understand you correctly.

Thanks Ben,

I tend to agree, that’s somewhere I’d rather not go at this point in time. Thanks for the info though.

Do you think it would be reasonable for us to ask Lotus (If you’re listening!) to have a think about changing the way these things are referenced so that lazy dunderheads like myself can get at objects a little bit more easily?

In the meantime, I think I’ll either use rich text fields with attachments, or take Normunds’ (Thanks to you as well) advice and pull out the sacrificial chicken. :slight_smile:

Cheers!

Brendan

6

Subject: *That’s not unfortunate at all … at least not for the rest of us.

7

Subject: RE: Re: They aren’t embedded. Embedded objects are attached, these are imported, if I understand you correctly.

as far as you only allow to import an image (“graphic”), the offset will always be the same (so you can hardcode it); with an upgrade to new Notes version you will need to test if anything changes (new CD records/different record length in new releases), but in general there should be no reason for the offset to change.

As for “rt lite” there is no option to save it as MIME, IMHO the only other option is to use some light practice of woodoo aka C API to find it out.

I’m not sure that the same goes about finding out the offset if you use OLE object. The idea is the same – the image for the object is stored at some offset in field, but as there is a bunch of records before it, I’m not sure how fixed it is, for example I think that if somebody changes the default image name you will have a different offset, so sacrifice of the chicken may be about the only option.

8

Subject: RE: Re: They aren’t embedded. Embedded objects are attached, these are imported, if I understand you correctly.

Actually, the offset can vary even if you just have a graphic, depending on whether you put alt text on it or not and that sort of thing, but if you don’t anticipate people doing that sort of thing, you can probably just get it once and use it.