Determining if s a parameter has been passed to a function

[new2access123 via AccessMonster.com]

Determining if s a parameter has been passed to a function

When I create a function the first thing I like to do in the function is
check thatr all the parameters have been passed. In FoxPro or C# I would
check for an empty string or NULL. I did some checking and found this…

Typed variables (that is, all variables other than variants) which do not
refer to objects and which have not been set, are initialized in VBA,
depending on their type:
- zero for numeric types
- zero-length string for string types

Only a Variant type variable can be NULL or EMPTY and detected with the
IsEmpty() or IsNull() functions

A parameter can only be Missing if it is untyped (declared as Optional Var2
or Optional Var2 As Variant), and will only be Missing if it is not supplied
by the calling code. To check if a parameter is missing use the IsMissing()
function.

So it sounds like the only way to know if a parameter has been passed is to
pass all parameters as variants and use IsMissing(). But I have also learned
from a thread here that it is bad form not to pass strongly type the input
parameters. On the other hand if I pass strongly type the input parameters
and a numeric parameter value, for example, is zero. I will not be able to
detect if the parameter was not passed or if VBA defaulted it.

Is there a technique I am messing?
Do I use bad form and make parameters variants?
Or do I not check?

How do you pros handle this?

Thanks

 

[Allen Browne]

You'll get different replies from different people, but my personal coding
style is to accept variants whenever it is appropriate do to so, e.g. *any*
time the function could be passed a Null, or any time you need to test form
missing as distinct from merely assuming a default value. That makes more
sense to me that trying to ensure that no null ever gets passed.

You can still test if the data type is appropriate by first testing that
it's not Missing or Error (essentially the same thing), and then testing for
the appropriate type (IsNumerc(), IsDate() or whatever.) A Null fails that
2nd test.

 

[new2access123 via AccessMonster.com]

That makes since. Thank you. I will follow your suggestions.

You'll get different replies from different people, but my personal coding
style is to accept variants whenever it is appropriate do to so, e.g. *any*
time the function could be passed a Null, or any time you need to test form
missing as distinct from merely assuming a default value. That makes more
sense to me that trying to ensure that no null ever gets passed.

You can still test if the data type is appropriate by first testing that
it's not Missing or Error (essentially the same thing), and then testing for
the appropriate type (IsNumerc(), IsDate() or whatever.) A Null fails that
2nd test.

Determining if s a parameter has been passed to a function

[quoted text clipped - 37 lines]

Thanks

 

[John Spencer]

I am in the minority, but I generally use the variant type for my procedure
parameters (arguments). I do this because most of my functions are working
with data that can be passed in from fields or forms and fields can always be
NULL and control values can always be null.

In rare cases where I have to process a LOT of data I will write a procedure
that is typed strongly and then make sure I pass in a valid data type.

Unless you are using the Optional keyword against the argument then I don't
see any reason to test since the procedure will error before you can test if
the argument is passed or if the argument is the correct type.

John Spencer
Access MVP 2002-2005, 2007-2010
The Hilltop Institute
University of Maryland Baltimore County

 

[Stuart McCall]

I am in the minority, but I generally use the variant type for my procedure
parameters (arguments). I do this because most of my functions are working
with data that can be passed in from fields or forms and fields can always
be NULL and control values can always be null.

<snip>

Have you tried using ByVal with a correctly typed param? That circumvents
the 'data type mismatch' and 'invalid use of null' errors. I assume this is
because its a value being passed, VBA has to create temp storage for it, so
it creates (coerces the value into) a variable. The default value for a
declared string is a zero length string, so that's what you get when a Null
is passed. For a numeric you get 0.

 

[Allen Browne]

Have you tried using ByVal with a correctly typed param? That circumvents
the 'data type mismatch' and 'invalid use of null' errors. I assume this
is because its a value being passed, VBA has to create temp storage for
it, so it creates (coerces the value into) a variable. The default value
for a declared string is a zero length string, so that's what you get when
a Null is passed. For a numeric you get 0.

Thanks for sharing that Stuart: could be useful sometimes.

In general I *hate* the implicit conversion that VBA does on things. It just
opens up more errors and makes it even harder to find the point at which
something goes wrong.

 

[Stuart McCall]

Thanks for sharing that Stuart: could be useful sometimes.

In general I *hate* the implicit conversion that VBA does on things. It
just opens up more errors and makes it even harder to find the point at
which something goes wrong.

Hi Allen

That makes a nice change, thanks. The last time I mentioned this was on the
msaccess forum on Compuserve (RIP), and a couple of the other sysops jumped
on me for revealing 'lazy programming style' to possible novices. I forget
the detail of their arguments, but I've been using the technique for years
and had no problems. I also don't see any problems with advising relative
novices of this in the correct circumstances. By that I mean that I wouldn't
recommend it for passing huge strings for instance, because a copy must be
made which far outweighs the conversion advantage.

I'm with you on the implicit conversions which are irritating, but I can see
how they might make life easier for the 'point, click and drag' style of
'development'.

 

[new2access123 via AccessMonster.com]

From this thread I have come up with this outline for :

Detecting if a parameter has been passed

If you strongly type the input parameters (that is, all variables other than
variants) which do not refer to objects and which have not been set, VBA
implicitly initialized the value of that variable depending on its type:
- zero for numeric types
- zero-length string for string types

If you need to check to determine if a parameter was passed you are forced to
violate our "always strongly type input parameters" rule. A parameter can
only be detected as Missing if the parameter is untyped (Variant type) and
Optional.

Function ReturnTwice(Optional A)
Function ReturnTwice(Optional A as Variant)

IsMissing() function can then be used to check if an optional parameter has
been passed to a user-defined procedure. IsMissing will return true if the
parameter has not been supplied by the calling code.

NOTE: Only a Variant type variable can be NULL or EMPTY and detected with the
IsEmpty() or IsNull() functions.

So use Variants whenever it is appropriate as in this case when you need to
test for a Missing parameter.

You can still test if the data type is appropriate by first testing that
it's not Missing() or Error () and then testing for the appropriate type
IsNumerc(), IsDate()

Something that I did not see and have not been able to find is how can I test
for a text data type? Is there a IsText() function or something like that?

 

[Dirk Goldgar]

Something that I did not see and have not been able to find is how can I
test
for a text data type? Is there a IsText() function or something like
that?

No, but there's a VarType function that tells you what type data is stored
in a Variant. You'll find it in the online help in the VB Editor
environment.

 

[new2access123 via AccessMonster.com]

That is what I was looking for. Thank you.

No, but there's a VarType function that tells you what type data is stored
in a Variant. You'll find it in the online help in the VB Editor
environment.