Shell is a function, which means it returns a value. In VB, however, you
have the ability to call any function as if it were a subroutine... the
function's value will still be calculated (it gets assigned to a memory
location consistent in size with the function's declared return value data
type), it just that the value won't be returned anywhere (the memory
location eventually gets cleared by VB's "garbage collection" routines
whether it was assigned anywhere or not). So the quick answer is the two
statements are the same. HOWEVER, that is only because you used the required
argument to the Shell function and omitted its optional second argument. IF
you had specified that optional second argument, your first statement would
have failed with an error whereas your second statement would still have
worked correctly. "Why is that?", I am sure you are asking. It has to do
with how subroutines are called in VB. The proper syntax for calling a
subroutine in VB are these...
YourSubroutine Argument1, Argument2, etc.
Call YourSubroutine(Argument1, Argument2, etc.)
Notice that the first calling method's syntax does not use parentheses
whereas the second one's syntax does. Whenever you use parentheses around
something in VB that is NOT required by syntax, VB treats it as an
expression to be evaluated. If the expression inside the parentheses is a
constant or variable reference, then it evaluates to itself. Now, let's
examine the two possible ways your originally posted first statement could
have been written...
Without 2nd argument: Shell ("R:\provaclick.exe")
or
With 2nd argument: Shell ("R:\provaclick.exe", 2)
where the 2 in the "with 2nd argument" example is the default value for that
argument when omitted (the 2 is assumed in the first example). Okay, as I
said, a SINGLE constant (or variable) value inside parentheses evaluates to
itself, so ("R:\provaclick.exe") gets evaluated to "R:\provaclick.exe" and
that ends up getting passed to the Shell function. However, in the second
example, ("R:\provaclick.exe", 2) is not an expression that VB can
evaluate... there are two terms with a comma instead of an operator between
them... that is meaningless to VB, so it doesn't know what to pass to the
Shell function and errors out instead. So, based on this, my advice when
would be to only use parentheses where they are required by syntax or for
grouping terms in an expression in order to force the order those terms are
evaluated in. Your first posted statement does not meet that criteria and,
so you don't end up scratching your head in the future when you end up
grouping multiple arguments in a subroutine call, I would recommend against
using it.
