Now that I can continue working easily on both my laptop and desktop it is time to recap the project and re-orient to get back to work on building the form auditor.

My current vision for the form auditor is to be able to create an instance of a form auditing class in an Access Form and connect it to the form where it will begin listening for updates, iterating over the form fields and collecting the changes while the form is open. There should be something that will allow us to retrieve all the changes and output them to various formats like a log file, table, and / or human readable output for clients (perhaps using some OO polymorphism).

I guess ultimately, my high level architecture is something like:

The FormAuditor class

• Setup Method (to configure)
• ChangedFields Property to return a dictionary of fields on the form with information about which changes were made and when they were made.
• OutputFields Method (to output the current list of changes to various formats or somewhere. Maybe this takes our polymorphic object configuring how the output will occur.

There will clearly be some testing for this. I have created a Test Form in Access I will use for testing the system to make sure it’s working properly. The auditing I am thinking will be looking at bound fields on the form (not checking unbound fields). I’ll have to have a few different types of fields eventually in a table and on the test form so I can test various types of controls that can be bound.

My original thoughts were to connect a listener to the form which would listen for beforeupdate events on the form and trigger an event to have a form iterator build a single snapshot of the changes at that time.

I am thinking though about the Cancel option within the BeforeUpdate event of the form. What would happen if some object were connected after mine and I recorded a change but it got canceled? Is that something I can do anything about? Should I consider a different architecture or maybe a verification in the AfterUpdate Event of the form to make sure it did indeed update and solidify the change?

I definitely don’t want to overthink from the beginning, but I do want to make sure I have a vision of what I want to end up with. Kind of like customer requirements for a project. I think most of what I laid out above puts some skin on a framework I want to be able to test ultimately for what we want the end results to be, not just to have tests for the sake of having tests.

It’s definitely a new way of thinking for me, so it’s good to keep reviewing this top level.

This should lead into some more testing in our next article. Stay tuned!