[AccessD] Problem adding a param. to a function

You could also call the function just like a Sub.
SeeDateInfo True, 1

Just wanted to clarify the confusion of parenthesis usage for others who
thought that there was some special rule for single argument functions.  In
actuality, the parentheses serve a completely different purpose, and have
nothing to do with the calling syntax.  

And for the ultimate in code obfuscation, you could also call your function
as
SeeDateInfo (2 > 1), (2 - 1)

Never heard about the external module rule with the Call statement.
Interesting.  I will have to look into that.

-----Original Message-----
From: Heenan, Lambert [mailto:Lambert.Heenan at aig.com]
Sent: Friday, May 07, 2004 9:03 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Problem adding a param. to a function


I agree fully with your comment about putting parentheses around an
expression resulting in the compiler being forced to evaluate the expression
as a different object - it's kind of like a Cast in C/C++, but this is not
the same thing as the "wrong" syntax I was talking about.

When you call Sub2 with it's argument in parentheses the compiler knows it's
still just an argument to the sub. That's why it puts a space between the
Sub name and the opening parenthesis.

But when you call a *Function* using this syntax

Call SeeDateInfo(True, 1) 

the compiler does not put a space between the function name and the opening
Parenthesis because it knows that it's dealing with a special variety of
function call, one that does not use the return value. Or to put it another
way, using Call tells the compiler to treat the routine called as a Sub not
a Function, but it requires the use of parentheses.

Also, in Access land at least, I do recall reading (though of course I
cannot turn up the reference right now) that if you call a sub or function
in an external module (a library mde for example) using just the routine's
name then the whole module is loaded into memory, but if you use Call
SomeSub in that case just the routine you use gets loaded into memory.
Something like that anyway.

Lambert

> -----Original Message-----
> From:	Brett Barabash [SMTP:BBarabash at tappeconstruction.com]
> Sent:	Thursday, May 06, 2004 6:05 PM
> To:	'Access Developers discussion and problem solving'
> Subject:	RE: [AccessD] Problem adding a param. to a function
> 
> Nothing odd about it.  And it's far from the "wrong" syntax.
> 
> When you place parenthesis around an expression, you are telling the
> compiler to evaluate the expression and pass its value, not its reference
> to
> the called routine.
> 
> Private Sub Sub1()
> 
>     Dim strThis As String
>     
>     strThis = "Hello, World!"
>     Sub2 strThis
>     Debug.Print strThis
> 
> End Sub
> 
> Private Sub Sub2(strArg As String)
> 
>     strArg = strArg & " How are you?"
> 
> End Sub
> 
> What result would you expect when you run Sub1?
> Answer: Hello, World! How are you?
> 
> This is because implicitly VB(A) passes arguments by reference (a pointer
> to
> a memory location) instead of by value (a copy of the memory location's
> contents).
> 
> Now...
> changing the calling syntax slightly:
> 
> Private Sub Sub1()
> 
>     Dim strThis As String
>     
>     strThis = "Hello, World!"
>     Sub2 (strThis)	'You could also use Call Sub2((strThis))
>     Debug.Print strThis
> 
> End Sub
> 
> Your are the compiler evaluates the expression, and passes its value to
> Sub2.
> Your result is Hello, World!.
> 
> BTW, the same result can be achieved by using the ByVal keyword in your
> argument definition
> i.e. Private Sub Sub2(ByVal strArg As String)
> 
> I follow this practice religously in all of my code, to avoid accidentally
> overwriting the calling routine's variable contents.  Many developers
> don't
> bother.  Don't know why.
> 
> 
> -----Original Message-----
> From: Mitsules, Mark S. (Newport News) [mailto:Mark.Mitsules at ngc.com]
> Sent: Thursday, May 06, 2004 3:35 PM
> To: 'Access Developers discussion and problem solving'
> Subject: RE: [AccessD] Problem adding a param. to a function
> 
> 
> 
> >> Oddly enough, you do not get this error when you call a function with
> only
> one argument using the "wrong" syntax. <<
> 
> I guess everyone learns the syntax in a different manner.  I was never
> taught that it was "wrong".  I was taught from the standpoint that the
> "Call" statement was optional if only one argument was passed and no
> return
> value was needed.  Otherwise, "Call" was required.  Funny...looking back,
> I'm guessing they considered it a "feature":)
> 
> 
> 
> Mark
> 
> 
-- 

--------------------------------------------------------------------------------------------------------------------
The information in this email may contain confidential information that 
is legally privileged. The information is only for the use of the intended 
recipient(s) named above. If you are not the intended recipient(s), you 
are hereby notified that any disclosure, copying, distribution, or the taking 
of any action in regard to the content of this email is strictly prohibited.  If 
transmission is incorrect, unclear, or incomplete, please notify the sender 
immediately. The authorized recipient(s) of this information is/are prohibited 
from disclosing this information to any other party and is/are required to 
destroy the information after its stated need has been fulfilled.

Any views expressed in this message are those of the individual
sender, except where the sender specifies and with authority,
states them to be the views of Tappe Construction Co.

This footer also confirms that this email message has been scanned
for the presence of computer viruses.Scanning of this message and
addition of this footer is performed by SurfControl E-mail Filter software
in conjunction with virus detection software.