And Take a Deep Breath....
Okay, I've calmed down a little now. Although I still want to invoice Lotus for lost time! It's not so bad when you're sat in the client's office, being paid by the day, but when you're working on a fixed-rate piece of development, from home, you really can't afford to be wasting days here and there!! Anyway, here's the cause of my grief:
We've all seen the way Domino adds attachments to the bottom of documents on the web. We've probably all seen how to hide them, using a mysterious field called "$V2AttachmentOptions". Don't ask me what a "V2" attachment is. I have no idea. All I know is that attachments are no longer "V2" (or hidden!) if you use anything other than "Using HTML" for your Web Access property of a Rich Text field, as below:
If you want to edit page content on the web using a tool like this and have it editable in the Notes client as Rich Text you have to use either the Java Applet or the "Best fit for OS" control. When you make this change, your content is then stored as MIME. 
When this happens, all your V2 attachments are moved to the first Rich Text field on the form. Not only that but they get displayed at the bottom of this field in a series of ugly tables like like this one. They are no longer V2 and are no longer hidden. As far as I know there's no "V{?}AttachmentOptions" field to hide them. The only way I've found to meet the following criteria is one ugly son of a hack.
- Content editable in Notes Client in a standard "Rich Text" field.
- Content editable in Browser as HTML, using third-party tool.
- Attachments displayed in the place you specify.
If anybody's interested in the method I came up with, I shall talk about it tomorrow. I warn you though, it ain't pretty.
Note: This isn't just another of my gripes from my stance as a control-freak developer. This is something that every user/manager/client is bound to find a problem. "Yeah, love the site, but can we move those attachments elsewhere?"
Skip to the 
You can subscribe to an individual
'Don't ask me what a "V2" attachment is.'
V2 = version 2. Since Release 3 attachments have been visible in the richtext field, before this they were shown beneath the field. I think "$V2AttachmentOptions" was a way to make Release 2 applications work running R3.
Similar to the "@V4UserAccess" in R5 and ND6.
Btw. I started to work with Notes at Release 3 and have only seen scr.dumps of Version 2. Any of you guys actually worked with Notes prior to Release 3?
You should N E V E R work for fixed-rate, especially when developing with Notes. You are always the jackass.
Good timing on this Jake. I have been fighting with similar problems. I am still on R5 and the Richtext Applet gets unstable if you need more than one on the page. I was hoping that the "Best Fit for OS" in 6 would help.
Attachments and compatibility in both Notes and Browser is giving me headaches. I am now looking at Alan Hurt's Method to see if I can use it. At least editing might be stable. Then I will will have to look at the Attachment problems.
Can you design the application so attachments are placed in their own RTF field?
Steve. You want to know how I did it then? Shall post it tomorrow.
Niel. My "solution" does takes this approach. That's one third of the hack ;o)
Can't wait :)
I guess Niel, you and I are thinking the same. I was also trying a seperate RT field for attachments.
What I am doing is adding that attachment to a RT field, putting that field on my form and then hiding it from web...
Works fine if you can make sure the attachment gets attached to the field (if not then some more coding would be required).
"Can you design the application so attachments are placed in their own RTF field?"
That would be my choice as well. I don't think the RTF text and the attachments should be in the same field anyway.
On the fixed-rate side of things I think mt69clp has got the right idea. You never know whats going to turn it's back on you with notes. It's hard enought giving a deadline and trying to meet it with notes.
@Niel: I agree. An extra disadvantage of putting attachments and text in the same RTF is that you have to re-replicate the whole attachment when you change one or more characters in the RTF fields'content. This puts an extra replication burden on all you users that replicate.
@laurens, am I the only one who no longer clings on to the "field replication" rubbish Lotus spouts out, am i?
I had this problem a couple of years ago. Really got on my wick and cost a lot in man hours to get round it. I ended up adding a hidden layer to the form, containing a rich text field.
Only worked in IE though, since When you addded layers to Netscape (at the time) would not display any fields after that layer.
$V2AttachmentOptions is a field to put at the bottom of a form in which you have attachments that have been uploaded via the web versus through the client in a RichText field.
I make the field computed for display.
The values for the field are "0" or "1".
"0" will hide the attachments at the bottom of the page,
"1" will let them show.
A 6.0 thing more on $V2AttachmentOptions:
In 6.0 there is an option to "Do not add field names to field index". The $V2AttachmentOptions field needs to be in the field index to work.
Putting a RTF on form and then hiding it from web is a great solution. It in fact solved the problem. Thank very much. Vietnamese colleague