Pass Values Between Forms in Access Without Using a Hidden Global Form

A common technique for getting user input in Microsoft Access is to call an unbound form in dialog mode and "return" the results via a hidden "Global" form.

I wrote about the GetInfo() convenience function that I use to implement this technique here:

Convenience Function for Passing Values Between Forms via a Hidden Global Form

I don’t always use a global form to stash user-provided values, but when I do, I use this GetInfo() function.

No Longer SetMike Wolfe

A Better Way

The problem with the above technique is that it relies on "global" state.

New developers love global state–variables and constants that you can call from anywhere in your program–because they seem to make things so much easier.  Passing arguments back and forth between procedures seems inefficient.  Why not just one variable in one place and be done with it already?

Part of the reason this is so appealing is that it is true...for simple projects.

As your application grows, though, the number of references to those global variables grows, too.  Once you exceed seven references, you can't even keep them all in your head at once.  Suddenly, you realize that every time you change that global variable that it could have side effects on other areas of your program.  

Each potential side effect is one more mental ball to juggle:

Managing Software Complexity: The Rule of Seven

Don’t try to increase the number of balls you can keep in the air; instead, reduce the number of balls needed to follow your software’s logic.

No Longer SetMike Wolfe

Any time we can avoid relying on global state, we reduce the complexity of our software.

BAD: Relying on the Global Form

We need a way to pause execution of our program while we wait for the user's input.

Here's how we solve that problem using the technique from my GetInfo() article:

1. Open an unbound form in dialog mode (this pauses code execution) to get data from the user
2. If user clicks OK on dialog form, copy all user-entered values to the global form
3. Close the dialog form (this allows calling code execution to continue)
4. Retrieve the values from the global form

Much of this technique is premised on the faulty assumption that the only way to continue code execution after opening a form in dialog mode is to close the form.  

As it turns out, simply hiding the form is enough to allow the code to continue executing.

GOOD: Hiding the Dialog Form

Here's the revised technique:

1. Open an unbound form in dialog mode (this pauses code execution) to get data from the user
    • If user clicks OK on dialog form, then hide it (Me.Visible = False)
    • If user clicks Cancel on dialog form, then close it
2. If dialog form is closed (i.e., user clicked Cancel) then exit the procedure, otherwise:
3. Retrieve the values from the hidden dialog form
4. Close the hidden dialog form after retrieving all user-entered data

Further Improvements

In the next installment, I'll share the convenience function I wrote to make the above technique easier to implement.  Stay tuned.

Cover image created with Microsoft Designer