I was going to ask for assistance when I discovered the cause of the odd behavior. I thought I'd mention it because it seems incredibly cryptic and in case anyone else encounters a similar situation. I'd like to know why this occurs if any of the experts can shed some light on it.
I'm invoking a procedure that registers UserForm metrics. The statement is:
Public Sub SaveFormSettings(FormReference As Variant)
I use the Variant type because UserForms are classes (different types). The user form uses the following call to save its metrics:
SaveFormSettings Me
I often called this from the QueryClose event of the userforms so that the locations and sizes could be restored using RestoreFormSettings on the subsequent run (the form metrics are no longer available at the UserForm Terminate event).
Recently, I developed an intermediate routine that, in addition to calling SaveFormSettings, performs additional work. I now call this intermediate routine in the QueryClose event. What that routine entails is:
Public Sub QueryCloseEvent(FormReference As Variant, Optional SaveSettings As Boolean = True)
And it does this:
If SaveSettings Then SaveFormSettings (FormReference)
There was no compilation error reported. However, the FormReference parameter is now of type "Controls" rather than a UserForm type, such as MyForm1, when it is passed to the SaveFormSettings method. When the routine tries to obtain the name of the form to create the registry key value, it encounters an error as a result of:
n = FormReference.Name & " Form Metrics"
This statement worked when I didn't have the intervening QueryClose function.
Now as it turns out, while typing up this question and analyzing my code for possible errors, I discovered that the problem is caused by the parentheses around the FormReference. When I changed the code to:
If SaveSettings Then SaveFormSettings FormReference ' <-- no parens
It now works as intended. Why?
