> > Actually, the problem is a subtle one...
> > >     mutate (a$): Debug.Print a$
>
> > See those parentheses you have around the a$ variable? Either add
the
> > keyword "Call" in front of the "mutate" Sub's
name or remove the
> > parentheses.
>
> It all made sense the second I saw the first sentence.  I didn't
realise
> that if the syntax was 'invalid' that the evaluated copy of the data
was
> sent though.

I see the quote marks, but just wanted to point out for later readers of
this thread.. the syntax is *not* invalid at all, that is the problem.
Had your Sub been defined with two or more arguments, VB would have
shown an error on the statement calling the Sub using parentheses but
without using the Call keyword. Why? Because two or more variables
separated by commas does not an expression make. However, one variable
inside of parentheses does make an expression, albeit a very simple one.
VB moves the value of the variable into a temporary memory location and
then looks for the operation to perform on it; finding none, it closes
down its internal expression evaluation mechanism and then sees what it
is supposed to do with the result it generated. VB gave you a clue that
it was doing this, but you missed it. I'll bet you typed the call to the
Sub this way

     mutate(a$)

without using a space between the Sub's name and the open-parenthesis.
Note that VB, recognizing that a call to a Sub was being made without
using the Call keyword, very politely straightened out the syntax by
inserting the space for you. By the way, one other place where this
"error" is VERY hard to see is when the Sub is expecting a control as an
argument. For example, if your Sub was


     Sub MySub(TBox As TextBox)
     .....

and you called it this way

     MySub (Text1)

you would get an error. Why? Because the non-syntax parentheses tell VB
to evaluate its contents. Objects themselves can't be evaluated as part
of an expression, but their properties can. Here, again, VB tries to be
helpful to us and fetches the default property for the control
attempting to be passed (the Text property for the example's TextBox)
which of course, doesn't match the expected argument type for the Sub...
instant error.

> That's interesting, and probably useful in some instances.

Not sure I agree. Even if you found a place where you could make use of
this fact, it would sure be confusing some 6 months or more from now
when you went to modify your code. Better would be to build in the
"duality" of operation inside the Sub itself (where I presume you would
document it).

Rick - MVP
---
þ RIMEGate(tm)/RGXPost V1.14 at BBSWORLD * Info{at}bbsworld.com

---
 * RIMEGate(tm)V10.2áÿ* RelayNet(tm) NNTP Gateway * MoonDog BBS
 * RgateImp.MoonDog.BBS at 6/22/04 5:38:35 PM