The sample database I'm providing at my Web site (at http://www.bigfoot.com/~jonathancoombs) contains a directly reusable Editor History tool, as well as some sample design elements to illustrate its functionality. I have seen many different edit history subforms in various Notes applications. The difference with this tool is that it combines several features into a single tool in order to reduce the number of tools that need to be maintained.

Implementation
This subform combines most of the functionality I've gleaned from the various editor history subforms I've seen. Typically, each flavor has certain hard-coded settings, such as the number of recent edits to display or the rules that determine when rows are generated.

For this tool, I picked my favorite combination of features and set it as the default. You can simply download the subform and plug it into a form, and it will work using the default settings. That is, it will store the last five editors and dates in a sort of "sliding window," as seen in Figure A.

FIGURE A

The default settings in action on the Notes client. Click picture for a larger image.

Every edit will generate a new row, and it will not prompt each editor to enter a description before saving. If you want to adjust any of these settings, you can add hidden control fields to the host form in which you placed the subform. These special fields can control the size of the sliding window, how often to create multiple rows if the same editor saves several times in a row, and whether to enable the Edit Descriptions feature.

Design standards
Before walking through the design and code behind the Editor History subform, I should explain some of the design standards I've used and part of the rationale behind them. The Edit History subform designer client is pictured in Figure B.

FIGURE B

Here's the Edit History subform designer client. Click picture for a larger image.

To minimize confusion, I have made all hidden fields small (8 point) and gray, and I've included bold labels next to each in case they need to be viewed for debugging or testing. I have also added a prefix to each field name--"f" for stored fields and "fd" for display fields--to distinguish them from field names that have special meaning in Notes (e.g., Form, SaveOptions, and Server_Name). An additional "EH" prefix causes the fields to sort together in the document properties box, and it protects against duplicate field names between the subform and its host form.