ms word - What is behind this difference in parentheses effect in VBA? -


i've not seen in other languages see lot in vba (which started working with). suppose have table in word , wish set rows height. if this

    tbl.rows.setheight inchestopoints(1), wdrowheightexactly 

the table's rows indeed set 72 points or 1 inch in height. however, if surround arguments in parentheses, did instinctively, vba gives error -- expected:=.

i can solve using throw-away variable, this

x = tbl.rows.setheight (inchestopoints(1), wdrowheightexactly) 

or, of course, can not surround arguments in parentheses.

microsoft's documentation on setheight method doesn't mention return value, in case, behavior extensive throughout vba. it's not specific setheight method.

my questions: called? should use throw-away variable or throw away parentheses? what's logic microsoft's point of view? there consequences using 1 or other, consequences can't imagine (because unknown unknowns)?

definitely don't introduce "throw-away variable", if it's not declared, , if you're invoking sub, procedure doesn't return value. can, if don't mind compile-time error:

expected function or variable.

now...

this behavior extensive throughout vba. it's not specific setheight method.

@yoe3k put nicely:

as called, guess "correct syntax" appropriate word.

that's whole answer: it's not setheight, it's how vba's implicit procedure/member call syntax works. explicit call syntax has been obsolete since wonderful advent of implicit calls, quarter of century ago. splattering call keywords left & right , on code will, indeed, keep parentheses... if hold them dear.

but "logic" of implicit call syntax isn't complicated, really.

what follows wrote on documentation.so vba , parentheses, hope helps.


this confusing. why not use parentheses?

parentheses used enclose arguments of function calls. using them procedure calls can cause unexpected problems.

because can introduce bugs, both @ run-time passing possibly unintended value procedure, , @ compile-time being invalid syntax.

run-time

redundant parentheses can introduce bugs. given procedure takes object reference parameter...

sub dosomething(byref target range) end sub 

...and called parentheses:

dosomething (application.activecell) 'raises error @ runtime 

this raise "object required" runtime error #424. other errors possible in other circumstances: here application.activecell range object reference being evaluated , passed value regardless of procedure's signature specifying target passed byref. actual value passed byval dosomething in above snippet, application.activecell.value.

parentheses force vba evaluate value of bracketed expression, , pass result byval called procedure. when type of evaluated result mismatches procedure's expected type , cannot implicitly converted, runtime error raised.

compile-time

this code fail compile:

msgbox ("invalid code!", vbcritical) 

because expression ("invalid code!", vbcritical) cannot evaluated value.

this compile , work:

msgbox ("invalid code!"), (vbcritical) 

but silly. avoid redundant parentheses.


Comments

Popular posts from this blog

Is there a better way to structure post methods in Class Based Views -

performance - Why is XCHG reg, reg a 3 micro-op instruction on modern Intel architectures? -

jquery - Responsive Navbar with Sub Navbar -