Michael,

What's wrong with VBs Const statement?

If you don't want to passed in parameter changed why not pass it ByVal?
...not sure I'm following you here...

;-) Cool
Hasta Luego
Adrian Maull, MCSD


    I just found out that you can force a ByRef Parameter to pass ByVal by
enclosing the argument in parentheses.  At first I thought this would be
great, because it would act like C's const keyword.
    Here's an example

    MyObject.MyMethod((Arg1),Arg2)

    But then a co-worker pointed out that it was evil because the person
that wrote the sub or function you are calling thinks they are getting a
ByRef and might try to change it but you have forced it to emulate ByVal.
Is there a better way to simulate C's const?

Evil??? Since when do morals enter the picture?

Enclosing it in parentheses does NOT cause it to be passed by value. It's
passed "by copy". VB creates a new, temporary variable "behind the scenes",
copies the data to the temp, and it ByRef to the sub. But any changes the sub
may make to the variable are NOT copied back to the original variable when
execution returns from the sub. The temp is destroyed.

As far as whether this is "right" or "wrong", in my book, the variable that's
passed as an argument to the sub "belongs" to the caller, not to the sub, and
the caller (not the sub) controls when and how its value is changed. If you are
forced to work with a sub that's been written to require the arguments passed
By Ref, you MUST pass them that way, and the only way to prevent the caller's
variable from being changed is to create a copy yourself and pass that copy, or
use the parentheses, which gets VB to do the extra work for you.

BTW, if you pass a constant (declared with a Const statement) to a routine
that's expecting a variable By Ref, the same thing happens. VB creates a
temporary variable, initializes it with the value of your constant, and passes
the address of that temporary variable to the sub.

But what do the assumptions made by the person who wrote the Sub have to do
with anything? If this variable is supposed to contain one of the outputs,
enclosing the variable in parentheses is equivalent to ignoring the output
value, which the caller certainly has the option of doing.

--

Hey, I appreciate the responses.  It's nice to know that there are
developers out there listening.  I guess my problem is that I wasn't clear
in what I was saying.

Take #2:

Q:  Why would you ever want to pass by reference anyway?

A:  When you are calling functions that use large arrays or, better yet,
large UserDefinedTypes into    a function you don't want all the overhead of
making a copy.  I'm working on a middleware piece that translates client
information and packages it to be sent off to a legacy server.  The client
sends 10k to 20k in a nested structure.  Processing has to be done to some
of the fields in this structure and passing by value is inefficient here.

Q:  Well in your case why don't you just pass by reference and quit your
whining?

A:  I am only one worker bee on this large team project.  No offense to my
co-workers, but many of them are boneheads.  When they are passed a
reference to an object they assume that means they have license to{*filter*}
with my data!  Now I could utilize the mammoth office leviathan known as
office politics and many meeting with upper-middle management to resolve
this.  Or I could insist that the functions involved pass a Const ByRef as a
parameter.  That way the bozo's I work with know that they are getting a
Reference for the efficiency, but they are not to mess with my structures.
If they want them changed, they have to negotiate with me.  They can't just
manipulate them in their functions.  I hope that is clearer.

Q:  Why do you put up with that kind of behavior?

A:  Eh, it's a living.

P.S.  Sorry if I offended anyone by feigning morality.   ;)

Don't worry...VB passes UDTs by reference anyway.

If you are passing a structure again, no need to worry about parm passing
inefficiency, because VB passes UDTs by reference anyway.

...I don't know what to tell you here...

No offense taken here...morality is a good thing.

;-) Cool
Hasta Luego
Adrian Maull, MCSD

I believe that when you reference a function in an out-of-process component
as you appear to be doing, Michael, it will *always* be done behind the
scenes by copying. In these cases, using ByVal is actually more efficient
than ByRef because in the latter case VB assumes it needs to copy the
results back as well.

Bertie

On Tue, 6 Apr 1999 16:06:30 -0500, "Michael Kelsey"

This is not evil.  Programmers should understand the language and pay
attention to what they write if they want their programs to work.
Sorry, but this is a pet peeve of mine and you're likely to hear more
about it.  New programmers are constantly stating how VB should behave
like the language they're used to.

The feature you're describing has been around since the very beginning
of MS Basic language releases (can you say CP/M or TRSDOS?).
Enclosing a variable in parenthesis has the effect of passing it byval
That is *protecting it* from the unknown (possibly evil) subroutine.

As Myrna said, it actually passes a copy under the hood.  From a
language standpoint it's not so important to understand how it's
implemented under the hood as to understand the effect.  

It is not evil.  It's a feature that allows you more control.  

Dan

On Wed, 7 Apr 1999 14:52:27 +0100, "Bertie Wooster"

This is correct, and it can make a big performance difference in some
circumstances.  As I said in another note in this thread, it has the
*effect* of passing byval.

Dan

I posted the following quote a while ago in response to another, similar
stream:

The following is quoted directly from "VB & VBA In A Nutshell - The
Language" by Paul Lomax (Copyright and Published by O'Reilly & Associates,
Inc.) on Pages 51-52:

"When passing variables to procedures that are either in the same project or
that are methods of an in-process ActiveX component, ByRef is much faster
than ByVal. This is because the memory reference gives the called procedure
almost instantaneous access to the variable's value.

However, when passing variables to a method in an out-of-process server,
ByVal has the performance advantage. This is because a procedure in a
different process can't use the reference supplied by ByRef. Since they
don't share memory, the called procedure has to obtain a copy of the
variable's value. But since parameters are usually passed by reference to
permit called routines to change their value, the value of the ByRef
argument is copied back to the calling procedure, and the original variable
is updated with this value."

...

I think though it's worth adding that it's a feature which is most often
used unknowingly, as in:

    MySub ( X )    ' instead of MySub X or Call MySub ( X )

Probably every VB program ever written contains an example, most of them
benign.

Bertie

Interesting.  I remember a time when CALL was required when paren's enclosed
the param's.

I guess that is progress, but I'm old fashioned and still use CALL.

David Phillips

On Wed, 7 Apr 1999 16:53:24 +0100, "Bertie Wooster"

You clearly know this, but I'll elaborate for those who don't...

You are right, this is a part of the definition that can be easily
overlooked if you don't understand it.  When using the Call keyword,
parenthesis are required around the parameters.  When *not* using the
Call keyword, parenthesis are required to be *missing*.  In this case
parenthesis are assumed to be a part of the parameter if they are
found.

This can lead to a bug if there is only one parameter.  VB would
assume the parameter is to be passed byval.  If there is more than one
parameter you'll get a syntax error if you try to do this.

Dan

Dan,

This is tricky for new folks.

FWIW, I have been teaching my way, way smart brother VB over the last couple
of weeks. He is doing a class design, has his head around huge concepts,
calls with detailed questions about how control arrays are different
critters, but he still gets caught by the darn parens on function/subs.
We'll give him another week or two.

--
Kathleen

<<"When passing variables to procedures that are either in the same project
or
that are methods of an in-process ActiveX component, ByRef is much faster
than ByVal. This is because the memory reference gives the called procedure
almost instantaneous access to the variable's value.>>

    Other than String variables, which are obviously a different animal, I
think the performance differences between ByRef and ByVal in an in-process
call are negligible at best. And they certainly don't outweigh the safety
factor gained by not having changes visible in the calling procedure when
they shouldn't be. Just my opinion.

--
Rob Bovey, MCSE
The Payne Consulting Group
http://www.payneconsulting.com
* Post follow up questions to this newsgroup *
* I do not respond to questions sent via e-mail *