Str strTopLeftCellIdentifier = "Account No"
I just tracked down the cause of my code triggering the error handler. it was that line not updating the value of strtopleftcellidentifier. Obviously, the first Str isn't meant to be there.
Yet, it will run that line.
I'm aware that Str() is a VBA function, but even with that, I don't understand how it's interpreting that line in any intelligible way.
What does the macro think it's doing and/or why isn't it causing an error?
Because Str() is a valid function name in VBA. So your statement is actually comparing strTopLeftCellIdentifier to "Account No" and passing the boolean result to Str(). It's the equivalent of:
Str False
And since you're not capturing the return value of Str(), parentheses are not required when making the call.
Related
I've not seen this in other languages but I see it a lot in VBA (which I just started working with). Suppose you have a table in Word and wish to set the rows to a certain height. If you do this
tbl.Rows.SetHeight InchesToPoints(1), wdRowHeightExactly
the table's rows indeed are set to 72 points or 1 inch in height. However, if you surround the arguments in parentheses, something I did instinctively, VBA gives an error -- expected:=.
I can solve this by using a throw-away variable, like this
x = tbl.Rows.SetHeight (InchesToPoints(1), wdRowHeightExactly)
or, of course, I can simply not surround the arguments in parentheses.
Microsoft's documentation on the SetHeight method doesn't mention any return value, but in any case, this behavior is extensive throughout VBA. It's not specific to the SetHeight method.
My questions: What is this called? Should I use a throw-away variable or throw away the parentheses? What's the logic from Microsoft's point of view? Are there consequences to using one or the other, consequences I can't imagine (because they are unknown unknowns)?
Definitely don't introduce a "throw-away variable", especially if it's not declared, and especially if what you're invoking is a Sub, a procedure that doesn't return any value. Well you can, if you don't mind a compile-time error:
Expected Function or variable.
Now...
this behavior is extensive throughout VBA. It's not specific to the SetHeight method.
#Yoe3k put it nicely:
As for what it is called, I would guess "correct syntax" is the most appropriate word.
That's the whole answer: it's not about SetHeight, it's about how VBA's implicit procedure/member call syntax works. The explicit Call syntax has been obsolete since the wonderful advent of implicit calls, about a quarter of a century ago. So splattering Call keywords left & right and all over your code will, indeed, keep you the parentheses... if you hold them so dear.
But the "logic" of the implicit call syntax isn't all that complicated, really.
What follows is what I wrote on Documentation.SO about VBA and parentheses, hope it helps.
This is confusing. Why not just always use parentheses?
Parentheses are used to enclose the arguments of function calls. Using them for procedure calls can cause unexpected problems.
Because they can introduce bugs, both at run-time by passing a possibly unintended value to the procedure, and at compile-time by simply being invalid syntax.
Run-time
Redundant parentheses can introduce bugs. Given a procedure that takes an object reference as a parameter...
Sub DoSomething(ByRef target As Range)
End Sub
...and called with parentheses:
DoSomething (Application.ActiveCell) 'raises an error at runtime
This will raise an "Object Required" runtime error #424. Other errors are possible in other circumstances: here the Application.ActiveCell Range object reference is being evaluated and passed by value regardless of the procedure's signature specifying that target would be passed ByRef. The actual value passed ByVal to DoSomething in the above snippet, is Application.ActiveCell.Value.
Parentheses force VBA to evaluate the value of the bracketed expression, and pass the result ByVal to the called procedure. When the type of the evaluated result mismatches the procedure's expected type and cannot be implicitly converted, a runtime error is raised.
Compile-time
This code will fail to compile:
MsgBox ("Invalid Code!", vbCritical)
Because the expression ("Invalid Code!", vbCritical) cannot be evaluated to a value.
This would compile and work:
MsgBox ("Invalid Code!"), (vbCritical)
But would definitely look silly. Avoid redundant parentheses.
The most serious consequence of using parentheses inappropriately can best be demonstrated by code such as:
Sub Test()
Dim r As Range
Set r = Range("A1")
TestSub r
TestSub (r)
End Sub
Sub TestSub(parm As Range)
MsgBox parm.Address
End Sub
In that code TestSub r correctly passes a range object to TestSub. However, placing parentheses around the r, i.e. TestSub (r) causes VBA to evaluate r using its Value property and is therefore equivalent to TestSub r.Value. This then gives an error as it is passing a Variant (maybe a Variant/Double with a value of 123.45) to a subroutine that is expecting a Range.
It is basically just incorrect syntax to enclose parameters to a Subroutine within parentheses. They should only be used when a Function is returning a value.
P.S. I apologise that my example is Excel VBA. I hadn't noticed that the question was Word VBA, plus I could knock up an Excel example quicker than I could research Word VBA enough to give an example in it. The principle is the same in both though.
I have problem with
Invalid use of null
error. I know how to avoid it with Nz, but it doesn't answer my problem.
I have a function, which builds sql query basing on data from recordset. Here's a (pseudo)code:
string = IIf(Nz(rst.Fields(0).Value, "") = "", "NULL", MyFunction(rst.Fields(0).Value))
The code produces NULL value, so I think it doesn't need to execute MyFunction function, but during the runtime I receive above error and it's caused inside MyFunction - why?
As is clearly stated in the documentation, VBA's IIf function will always evaluate both the truepart and the falsepart.
If you want to to avoid executing the falsepart you will need an actual If-Then-Else block or a Select-Case statement in VBA.
You could modify to:
Dim NullValue As Variant
NullValue = <some value that will not cause MyFunction to fail>
string = IIf(IsNull(rst.Fields(0).Value), "NULL", MyFunction(Nz(rst.Fields(0).Value, NullValue))
I've not seen this in other languages but I see it a lot in VBA (which I just started working with). Suppose you have a table in Word and wish to set the rows to a certain height. If you do this
tbl.Rows.SetHeight InchesToPoints(1), wdRowHeightExactly
the table's rows indeed are set to 72 points or 1 inch in height. However, if you surround the arguments in parentheses, something I did instinctively, VBA gives an error -- expected:=.
I can solve this by using a throw-away variable, like this
x = tbl.Rows.SetHeight (InchesToPoints(1), wdRowHeightExactly)
or, of course, I can simply not surround the arguments in parentheses.
Microsoft's documentation on the SetHeight method doesn't mention any return value, but in any case, this behavior is extensive throughout VBA. It's not specific to the SetHeight method.
My questions: What is this called? Should I use a throw-away variable or throw away the parentheses? What's the logic from Microsoft's point of view? Are there consequences to using one or the other, consequences I can't imagine (because they are unknown unknowns)?
Definitely don't introduce a "throw-away variable", especially if it's not declared, and especially if what you're invoking is a Sub, a procedure that doesn't return any value. Well you can, if you don't mind a compile-time error:
Expected Function or variable.
Now...
this behavior is extensive throughout VBA. It's not specific to the SetHeight method.
#Yoe3k put it nicely:
As for what it is called, I would guess "correct syntax" is the most appropriate word.
That's the whole answer: it's not about SetHeight, it's about how VBA's implicit procedure/member call syntax works. The explicit Call syntax has been obsolete since the wonderful advent of implicit calls, about a quarter of a century ago. So splattering Call keywords left & right and all over your code will, indeed, keep you the parentheses... if you hold them so dear.
But the "logic" of the implicit call syntax isn't all that complicated, really.
What follows is what I wrote on Documentation.SO about VBA and parentheses, hope it helps.
This is confusing. Why not just always use parentheses?
Parentheses are used to enclose the arguments of function calls. Using them for procedure calls can cause unexpected problems.
Because they can introduce bugs, both at run-time by passing a possibly unintended value to the procedure, and at compile-time by simply being invalid syntax.
Run-time
Redundant parentheses can introduce bugs. Given a procedure that takes an object reference as a parameter...
Sub DoSomething(ByRef target As Range)
End Sub
...and called with parentheses:
DoSomething (Application.ActiveCell) 'raises an error at runtime
This will raise an "Object Required" runtime error #424. Other errors are possible in other circumstances: here the Application.ActiveCell Range object reference is being evaluated and passed by value regardless of the procedure's signature specifying that target would be passed ByRef. The actual value passed ByVal to DoSomething in the above snippet, is Application.ActiveCell.Value.
Parentheses force VBA to evaluate the value of the bracketed expression, and pass the result ByVal to the called procedure. When the type of the evaluated result mismatches the procedure's expected type and cannot be implicitly converted, a runtime error is raised.
Compile-time
This code will fail to compile:
MsgBox ("Invalid Code!", vbCritical)
Because the expression ("Invalid Code!", vbCritical) cannot be evaluated to a value.
This would compile and work:
MsgBox ("Invalid Code!"), (vbCritical)
But would definitely look silly. Avoid redundant parentheses.
The most serious consequence of using parentheses inappropriately can best be demonstrated by code such as:
Sub Test()
Dim r As Range
Set r = Range("A1")
TestSub r
TestSub (r)
End Sub
Sub TestSub(parm As Range)
MsgBox parm.Address
End Sub
In that code TestSub r correctly passes a range object to TestSub. However, placing parentheses around the r, i.e. TestSub (r) causes VBA to evaluate r using its Value property and is therefore equivalent to TestSub r.Value. This then gives an error as it is passing a Variant (maybe a Variant/Double with a value of 123.45) to a subroutine that is expecting a Range.
It is basically just incorrect syntax to enclose parameters to a Subroutine within parentheses. They should only be used when a Function is returning a value.
P.S. I apologise that my example is Excel VBA. I hadn't noticed that the question was Word VBA, plus I could knock up an Excel example quicker than I could research Word VBA enough to give an example in it. The principle is the same in both though.
I'm trying to save an activeworkbook but when I use the following code, I keep getting the error "compile error: expected function or variable" with the word "format" highlighted.
It boggles my mind because I used the exact same function and format in another macro and it saved the file perfectly. I also made sure they had the same types of variables defined already...
Here's the one line code
ActiveWorkbook.SaveAs Filename:=SavedPath & format(Date, "mmddyyyy") & " 4512 GLUpload.xlsm"
The variable savedpath is fine because when I run this line without the format part, it saves the file, but not sure why this screw it up. Also noticed in my other code, format is capitalized but it's not here.
The compiler error you are getting indicates that VBA is expecting an assignable value (either a literal, a variable, or the return value of a function). This means that one of the identifiers in the statement to the right of the equals sign doesn't fall into those categories. So, either SavedPath is defined somewhere as Sub SavedPath(), or there is a Sub Format(arg1, arg2) defined somewhere (if it had a different number of arguments you would get a "Wrong number of arguments or invalid property assignment" error). The second clue (in the comments) is that changing format to the strongly typed Format$ gave a "Type-declaration character does not match declared data type" error. This points to the compiler not treating the symbol format as a function call (Format$() is the strongly typed version of Format()). The solution is to track down the errant use of the VBA function name and re-name it.
A perfect example of why avoiding VBA keywords and function names is good practice.
In Access 2007 The code below gives Error 2434: The expression you entered contains invalid syntax.
If (Eval("DLookUp(""[BaseRate]"",""RATELOOKUP"",""|DatePart(""yyyy"",[TxDate])| & |DatePart(""m"",[TxDate])| = [RATELOOKUP].[PERIOD]"") Is Null")) Then
' Checks for Current Base Rate
Beep
MsgBox "Interest Rate required for this month", vbExclamation, ""
End If
The error appears to be in the first line.
Proper quoting within the string expression you give to Eval() can be very challenging. Here is what Eval() actually sees within your code:
DLookUp("[BaseRate]","RATELOOKUP","|DatePart("yyyy",[TxDate])| & |DatePart("m",[TxDate])| = [RATELOOKUP].[PERIOD]") Is Null
Consider a different approach when using Eval(), one which allows you to see exactly what you're asking Eval() to evaluate.
Dim strEval As String
strEval = "your expression here"
Debug.Print strEval ' <- examine the string Eval() receives
' finally ...
If Eval(strEval) ...
However, this thing looks way too complicated to me, so I suspect there should be a simpler solution which doesn't even require Eval(). Unfortunately your DLookup Criteria argument is so confusing I got lost. But I suspect the IsNull() function might give you what you want without needing Eval():
If IsNull(DLookup("BaseRate","RATELOOKUP", "your Criteria here")) = True Then