Part of the art of customizing the mail template is doing it in such a way that the maintenance effort is as little as possible each and every time IBM release a new version of the mail template. The following is one suggestion for reducing the footprint of your customizations.
1) Add a "Custom" subform to the Memo & Response forms (either one each or one common subform)
2) Add any number hidden fields to the subform needed to add additional internal data to mail documents
3) Add any number of actions that you would like to appear. Granted you do not full control over where these actions appear compared with modifying the forms themselves, but I can live with this compromise to reduce the impact of the changes.
4) Procedural Programmers:
4.1) Add code to each action to define what each action should do
4.2) Add code to the QueryOpen, PostOpen etc events of the subform as a way of customizing what happens when the form is processed.
5) Object Oriented Programmers:
5.1) Create two new classes one for the foreground document and one for the background document
e.g.
Class DominoUIMemo
Private iNotesUIDocument As NotesUIDocument
....
Class DominoMemo As NotesDocument
Private iNotesDocument As NotesDocument
....
5.2) Wire the QueryOpen event to instantiate the above classes
5.3) Modify the UI class to trap any form events as part of the constructor.
e.g.
Sub New(Source As NotesUIDocument)
On Event PostOpen From Source Call OnPostOpen
On Event PostSave From Source Call OnPostSave
End
5.4) Add methods/properties to either class to support the custom Actions
The above will not handle all the likely mail customizations needed but it is a good start and each time a new mail template is released there is a single change needed to the existing IBM code - adding the "custom" subform.
Note: Adding subforms does have a performance impact, but given the number of subforms already included in the standard mail forms and the amount of processing that takes place it is unlikely to be noticeable.
0
1
0
1 Tim Tripcony Permalink Quick warning: LotusScript won't allow sub-classing of product objects, so you can't derive a class directly from NotesDocument / NotesUIDocument. You'd have to provide a different parent type (or just create the wrapper as a base class).
2 Peter Presnell Permalink @1 Good point. I must have been asleep when I wrote this blog entry, fantasizing about the day when IBM makes such a feature available. I have modified the example code to reflect the need to define a Private Property for the class containing the product objects.