[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


-----Original Message-----
From: Heenan, Lambert [mailto:Lambert.Heenan at aig.com] 
Sent: Thursday, May 06, 2004 4:26 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Problem adding a param. to a function


Shame you did not quote the actual line of code that's giving the error, but
I think I've worked it out anyway.

You can "Call" a function in (at least) 3 ways

1/ 	x = FunctionName(parameters...)

2/ 	FunctionName parameters...

and

3/ 	Call FunctionName(parameters...)

Only the first one actually used the return value of the function, the other
two are examples of using a function as a Sub.

So if your code looks like this

x =  SeeDateInfo(True, 1) 

then it will run just fine and you'll get a return value in x, but if the
code looks like this

SeeDateInfo(True, 1) 

then you will get the compile error "Expected =" as you are not using the
return value yet you are using the function call syntax. If you don't want
the return value then call it like this

Call SeeDateInfo(True, 1) 

or

SeeDateInfo True, 1

Oddly enough, you do not get this error when you call a function with only
one argument using the "wrong" syntax.

Lambert

> -----Original Message-----
> From:	John Clark [SMTP:John.Clark at niagaracounty.com]
> Sent:	Thursday, May 06, 2004 3:05 PM
> To:	accessd at databaseadvisors.com
> Subject:	[AccessD] Problem adding a param. to a function
> 
> OK...this is probably something boneheaded and simple, but I haven't
> posted any problems in a while, and my head feels like it is going to
> explode from behind my eye sockets, so please bare with me...
>  
> I have been asked to do some alterations/additions to a program that I
> wrote, a little over a year ago. What I am working on now is the simple
> addition of a new report. I usually leave some 'reserved' buttons on my
> Reports Menu because they always want more reports, so the buttons are
> already there.
>  
> On my reports menu, I have hidden fields to accomodate a couple of the
> different reports. These fields become visible, depending on the report
> chosen--I have one that uses 'Start Date' and an 'End Date' fields, and
> another that uses a drop-down to choose an employee. These also each
> have a cancel button, and a proceed button. After you cancel or proceed,
> the main buttons, which were disabled, when one was chosen, are
> re-enabled, and the used fields become invisible again.
>  
> This report that I have added is also dependent on a starting and
> ending date, so I used the same function to do the button magic (i.e.
> disappear, reappear, setfocus, enable, etc.). However I needed an extra
> IF statement to decipher which of two buttons was chosen. So I added the
> if statement and added a parameter to go with it:
>  
> Function SeeDateInfo(Mode As Boolean)
>  
> has become
>  
> Function SeeDateInfo(Mode As Boolean, Button As Integer)
>  
> but when I change the function call to add another parameter, the help
> tip comes up correctly--it tells me what it is looking for--but I get an
> error:  Compile Error ... Expected: =
>  
> What in the hey am I doing wrong?!
>  
> Thanks for the help...now and in the past!
>  
> I gotta fly now to get my daughter's tooth yanked...arrrrghtt!!!
>  
> btw...A97
>  
> John W Clark
> -- 

--------------------------------------------------------------------------------------------------------------------
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.