R6’s in-place editing and deletion of attachments, while a welcome innovation, has created serious problems for certain application designs. In Notes 4/5, you could prevent inadvertent editing or deleting of attachments under specified conditions by using QueryOpen and QueryModeChange to prevent a document from going into edit mode.
Unfortunately, due to some glaring anomalies in R6, it is now much more difficult to provide this protection. I thought that it would be useful to document these for the benefit of anyone else struggling with the same problems. (These results were obtained on version 6.5).
Anomaly 1.
Note in read mode. Right-click attachment and select Edit. Querymodechange fires, but script sets Continue = False (because application designer does not want to permit editing).
Result: note stays in read mode, but attachment is still opened for editing in registered application. After editing attachment, user closes note. Asked whether to save changes (and querysave fires - this could never happen from read mode before). If answer is yes, error message says “You must be in edit mode to attach files to this document”. On the positive side, this prevents modification of the attachment, but it does mean that user’s editing efforts have been wasted.
Preferred behaviour: if Continue = False in querymodechange, attachment should not be opened for editing.
Anomaly 2.
Note in read mode. Right-click attachment and select Delete. Querymodechange fires, but script sets Continue = False for same reason.
Result: note stays in read mode, but attachment is deleted. If note is closed, user is asked whether to save changes (and querysave fires). If answer = Yes, note is saved with attachment removed. In this case, therefore, attachments have not been protected from deletion.
Preferred behaviour: if Continue = False in querymodechange, no attempt should be made to delete the attachment.
Anomaly 3.
Same situation as anomaly 2, except that attachment is double-clicked to open Attachment Properties and Delete is selected from there.
Result: note goes into edit mode, without firing querymodechange or postmodechange!!! Attachment is also deleted. It is now possible to edit anything on the note, with the application designer having no way of detecting it has happened.
In considering possible solutions, you encounter several problems.
Anomaly 1 is difficult to avoid, except by providing a warning in querymodechange. Looks very inelegant from user viewpoint.
Anomaly 2&3 needs a Continue = False in querysave. This is not sufficient however. You must be absolutely sure that nothing will cause a backend save between the time that you pressed delete and the document is closed again. Otherwise you are left with an attachment icon and no $File.
Also, if the note goes into edit mode due to anomaly 3, the user might be able to change the conditions under which editing is not permitted, so querysave protection could be lost.
If anyone can think of better solutions, please let us know. And if anyone is in a better position than me to feed these points to Lotus, please do so. They really must be fixed.