Evolution of a Function: ShowForm()

This is the introduction to a series on the evolution of my ShowForm() function.

• Part 1: Minimum Viable Product (MVP)
• Part 2: Multiple Form Instance Support
• Parts 3+: (Not yet published)

There are 4 keys to building generic solutions in code:

1. Avoid premature generalization by sticking to the Rule of Thrice
2. Make sure any additional time spent building a generic solution is worth it
3. Build only what you need at first; don't try to anticipate future use cases
4. Maintain backward compatibility as you add features

To illustrate points 3 and 4, I'm going to take you with me on a journey through the development of one of the foundational building blocks of my Access applications: my ShowForm() function.

The ShowForm() Function

At its most basic, the ShowForm function acts as a wrapper around the built-in DoCmd.OpenForm method.

Over time, the function grew to encompass the following features:

• Simplify calling code by eliminating the View and FilterName arguments
• Avoid "Syntax error (missing operator) in query expression 'MyField = '." errors
• Force-apply new filter criteria to already-open forms*
• Restore the form being opened if it is currently minimized*
• Reveal the form being opened if it is currently hidden*
• Support multiple form instances with no change to the calling code
• Avoid creating duplicate form instances (based on WhereCondition and OpenArgs arguments)
• Automatically cascade multi-instance forms (to avoid obscuring other instances of the same form)
• Return the window handle of the newly opened form (to track specific instances of a multi-instance form)

^{*NOTE: Features with asterisks in the list above appear to be built into the latest versions of Access, though I swear they were missing in earlier versions (e.g., Access 2000).}

Through a series of follow-up articles, I will show you how this function evolved and grew over a period of several years.  

From its humble beginnings to its current grandeur, this function is a great example of the power of Just-In-Time development mixed with reverence for backwards compatibility.

The Value of Version Control

I should point out the thing that makes this article series possible is my long and consistent use of version control to maintain my code library:

Scraps of Wood and Code

Resisting the packrat mentality.

No Longer SetMike Wolfe

Without version control, I'd be able to show you the code for the function as it is now, but I would have no way to show you how it evolved over time.  Being able to see how code evolves is a powerful way to gain insight into why a piece of code works the way it does.

Image modified from Wheel of Fortune template on Kapwing.com