RE: Code Hanging - Part II by JeanGuyMarcil
JeanGuyMarcil
Mon Apr 07 06:15:02 PDT 2008
"NZ VBA Developer" wrote:
> Thanks for the feedback, Jean-Guy. I think I see what you're driving at, but
> it's really a case of 'six of one/half dozen of the other', isn't it? Either
> the 'OK' button sets a flag itself or it calls the data collection module
> that sets a flag. Unless I'm missing something, which is entirely possible, I
> don't see much difference between the two. However, I do see a few small
> advantages with calling a separate procedure (forgive me for calling it a
> 'module' in my previous post - just a slip of the keyboard):
>
> First, I find it easier to keep track of what's being collected from the
> UserForm if the collection process is in its own separate space rather than
> embedded in the code that is primarily devoted to the loading and display of
> the UserForm. If I miss a value or something goes wonky, this method makes it
> simple to find where to look; just insert a break point at the start of the
> procedure.
>
> In addition, I see the collected data as be more document-related and
> secondary to the UserForm itself. Therefore, the separate procedure is in
> keeping with my rule that says, 'Don't mix your drinks!' ;-D Procedures
> should be based around the objects and processes they're intended to support
> - rather like your rule of keeping the code in the UserForm to only what is
> required to support the form, altho at a bit finer granularity.
>
> Finally, I don't have to worry about 'transporting variables across state
> lines'. The bAddEnvelope flag is declared in the main module, initialised and
> set in the main module, and evaluated and acted on in the main module. No
> public global variables to try and track between modules; the only thing that
> crosses between them are the values from the controls on the UserForm (which
> are much more 'visible' than variables).
>
> However, there may be advantages to your method that I'm just not seeing. If
> so, please let me know as I'm always eager to learn. And I may give your
> suggestion a go just for the experience of working with passing variables
> between modules.
I guess, especially since you seem to be dealing with a simple case of a
single userform, you summed it up nicely with "it's really a case of 'six of
one/half dozen of the other', isn't it?"
The only issue I migth have with your code is the second sub:
Sub CollectUserFormValues()
bAddEnvelope = True
RecipName = frmEnvelopeDetails.txtRecipientName
RecipAddressL1 = frmEnvelopeDetails.txtRecipientAddressL1
RecipAddressL2 = frmEnvelopeDetails.txtRecipientAddressL2
RecipSuburb = frmEnvelopeDetails.txtRecipientSuburb
RecipCity = frmEnvelopeDetails.txtRecipientCity
RecipPostCode = frmEnvelopeDetails.txtRecipientPostCode
RecipAttention = frmEnvelopeDetails.txtRecipientAttention
End Sub
Here, "frmEnvelopeDetails" is not the name of the userform object (the name
is actually "frmMyForm"), but the name of the class module that contains the
blue print of the userfrom. If you had two userforms for that class module in
memory, this code would not know which one to address, and might address the
wrong one.
I know that in your case it is very unlikely that it would happen, but
personally, I always like to be in total control and use the actual instance
of an object I create, which your code does not do. It works with the class
name, but it just so happens that there is only one instance of an object
created by that class in memory when that sub is called; so it works, not
because it is well coded, but by default...
But I guess I am splitting hair since your code seem simple enough so that
there won't be a case where you have two instances of the form in memory at
the same time...
I guess you could still use the second sub, but pass the userform object and
use that instead of the class name...
Finally, you stated :
"The bAddEnvelope flag is declared in the main module, initialised and
set in the main module, and evaluated and acted on in the main module. No
public global variables to try and track between modules".
Actually, you do have a "cross the state line" case. In your previous post,
you stated:
"The 'CollectUserFormValues' module is called in the
Click event for the 'OK' button. This module not only collects the values
from the UserForm for use in the 'Envelopes and Labels' dialog, but also sets
the bAddEnvelope flag to 'True'. (Clicking the 'Cancel' button just hides the
form and leaves the flag set to 'False'.)"
So, your flag *is* a global variable used in a few subs in the main module
and in the userform module, which is a separate class module. With my
approach, it is not a global variable, but a property of the userform object.
But again, we are back at "Tomayto" "Tomahto"! I prefer my approach because
I do not like having global variables if I can avoid it, for the exact
reasons you stated.