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
Related
I'm struggling with this basic piece of code :
If Dir(LocationAddress & "\" & chart & " Complete.pdf") = "" Then
MsgBox("The file wasn't created.", vbCritical + vbRetryCancel)
Else
MsgBox ("The file was created.")
End If
When I click "save" in the VBA editor, the line corresponding to the error message turns red, and when I try to execute, it tells me there's a syntax error. I found this similar code online, with a different syntax, which also doesn't work, even when copied and pasted into the editor.
MsgBox("Important message", MsgBoxStyle.Critical, "MsgBox Example")
I also ran my initial code with only one style instruction as an optional argument, to make sure the issue wasn't simply that I was combining them with improper syntax.
I hardly know anything about vba, I've only written a few subs by copying and editing code found online.
As igittr commented above, on the line MsgBox("The file wasn't created.", vbCritical + vbRetryCancel), the parenthesis aren't needed.
When there's only one statement on the line, then VBA knows that the arguments are for the MsgBox procedure. If you put brackets around the arguments, it will try to evaluate everything within the brackets first, resulting in the error (that's why MsgBox ("The file was created.") still works, even though the brackets again aren't needed).
So either write the line as MsgBox "The file wasn't created.", vbCritical + vbRetryCancel
Or, if you want to still use brackets, use Call MsgBox("The file wasn't created.", vbCritical + vbRetryCancel). This works because you have two statements, Call and MsgBox, and the brackets are needed to indicate what procedure the arguments belong to.
Since, you show the message with some buttons option, the working solution should look as:
Dim ans As VbMsgBoxResult
ans = MsgBox("The file wasn't created.", vbCritical + vbRetryCancel, "A choice...")
If ans <> vbRetry Then Exit Sub ' the code will stop even if the right corner 'x' will be clicked.
'your code if want it continuing...
'or viceversa according to what do you intend doing in case of Cancel option.
MsgBox("The file wasn't created.", vbCritical + vbRetryCancel)
This won't work as you are calling a function as a sub. When calling functions as subs it needs to be treated as a sub which means no brackets. This is core Basic - brackets for functions and no brackets for subs.
MsgBox ("The file was created.")
This will work because you aren't using brackets for the sub. Brackets around a parameter mean pass that parameter by value. Where ever possible computer languages pass by reference as it more efficient.
However it means that the string is copied, and the copy given to msgbox. So it uses more memory.
Call
call is obsolete. In QuickBasic it allowed a different calling convention when calling inline assembler functions. Assembler didn't return a value. So the convention was to pass a variable by reference as an input parameter and on return would hold the return value.
Dir
Dir is obsolete. It became obsolete in the 90s when it was replaced by the file system object. See https://learn.microsoft.com/en-us/office/vba/language/reference/user-interface-help/filesystemobject-object
Brackets in Basic
From https://ericlippert.com/2003/09/15/what-do-you-mean-cannot-use-parentheses/
The author was the maintainer programmer at Microsoft for VBScript.
Here’s the deal: parentheses mean several different things in VB and
hence in VBScript. They mean:
Define boundaries of a subexpression: Average = (First + Last) / 2
Dereference the index of an array: Item = MyArray(Index)
Call a function or subroutine: Limit = UBound(MyArray)
Pass an argument which would normally be byref as byval: in Result
= MyFunction(Arg1, (Arg2)) , Arg1 is passed by reference, Arg2is passed by value.
That’s confusing enough already. Unfortunately, VB and hence VBScript
has some weird rules about when #3 applies. The rules are
3.1) An argument list for a function call with an assignment to the returned value must be surrounded by parens: Result = MyFunc(MyArg)
3.2) An argument list for a subroutine call (or a function call with no assignment) that uses the Call keyword must be surrounded by
parens: Call MySub(MyArg)
3.3) If 3.1 and 3.2 do not apply then the list must not be surrounded by parens.
And finally there is the byref rule: arguments are passed by reference
when possible but if there are “extra” parens around a variable then
the variable is passed by value, not by reference.
Trivia
The msgbox function is a wrapper around the Windows MessageBox() functions. Basic passes on verbatim any parameters you pass. Of course only on Windows can you use the system parameters not listed in the Basic docs. See https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-messagebox
I have an If clause that was being completely ignored, until I discovered a workaround, but now I'd like to better understand what is happening under-the-hood.
We have a form with a ComboBox that gets populated, but a default value is not set on it. When I go to save the form, we need to test if the user selected a value. The code was:
If (Me.Combo78.Value = "") Then
mb "Please select a value"
End If
The code would never fire, until I changed the condition to read:
If ("" & Me.Combo78.Value = "") Then
mb "Please select a value"
End If
I'm guessing that the "" & forces the comparison to be a text comparison, and therefore can validly test against the empty string "", but what was the previous comparison actually doing, and is there a better, more intuitive way to manage this? The solution I have just feels gross.
-- 30 years experience with coding in Pascal, HTML, Javascript, but <1 year coding in VBA, after being handed a legacy application that needs debugging.
If the ComboBox has no value then Me.Combo78.Value will be null and consequently Me.Combo78.Value = "" will be null and will not validate the test expression for the if statement.
In your second code, concatenating an empty string with a null value will return an empty string, and so "" & Me.Combo78.Value returns an empty string, thus validating the test expression.
If you wish, you can verify this for yourself in the VBE Immediate Window (accessible using Ctrl+G):
?Null = ""
Null
?Null & "" = ""
True
A more readable solution might be:
If IsNull(Me.Combo78) Or Me.Combo78 = "" Then
mb "Please select a value"
End If
Alternatively, you could use the Nz function:
If Nz(Me.Combo78, "") = "" Then
mb "Please select a value"
End If
Since the Value property is the default member for this class, it may be safely omitted.
I am learning how to create input boxes and I keep getting the same error. I have tried two different computers and have received the same error. The error I get is a "Compile Error: Wrong number of arguments or invalid property assignment"
Here is my code:
Option Explicit
Sub InputBox()
Dim ss As Worksheet
Dim Link As String
Set ss = Worksheets("ss")
Link = InputBox("give me some input")
ss.Range("A1").Value = Link
With ss
If Link <> "" Then
MsgBox Link
End If
End With
End Sub
When I run the code, it highlights the word "inputbox"
And help would be greatly appreciated.
Thanks,
G
Three things
1) Call your sub something other than the reserved word InputBox as this may confuse things. *Edit... and this alone will resolve your error. See quote from #Mat's Mug.
2) A̶p̶p̶l̶i̶c̶a̶t̶i̶o̶n̶.̶I̶n̶p̶u̶t̶B̶o̶x̶(̶"̶g̶i̶v̶e̶ ̶m̶e̶ ̶s̶o̶m̶e̶ ̶i̶n̶p̶u̶t̶"̶)̶ Use VBA.Interaction.InputBox("give me some input"). You can do this in addition to the first point. Documentation here.
3) Compare with vbNullString rather than "" . See here. Essentially, you will generally want to do this as vbNullString is, as described in that link, faster to assign and process and it takes less memory.
Sub GetInput()
Dim ss As Worksheet
Dim Link As String
Set ss = Worksheets("ss")
Link = VBA.Interaction.InputBox("give me some input")
ss.Range("A1").Value = Link
' With ss ''commented out as not sure how this was being used. It currently serves no purpose.
If Link <> vbNullString Then
MsgBox Link
End If
' End With
End Sub
EDIT: To quote #Mat's Mug:
[In the OP's code, what is actually being called is] VBA.Interaction.InputBox, but the call is shadowed by the procedure's identifier "InputBox", which is causing the error. Changing it to Application.InputBox "fixes" the problem, but doesn't invoke the same function at all. The solution is to either fully-qualify the call (i.e. VBA.Interaction.InputBox), or to rename the procedure (e.g. Sub DoSomething(), or both.
Sub InputBox()
That procedure is implicitly Public. Presumably being written in a standard module, that makes it globally scoped.
Link = InputBox("give me some input")
This means to invoke the VBA.Interaction.InputBox function, and would normally succeed. Except by naming your procedure InputBox, you've changed how VBA resolves this identifier: it no longer resolves to the global-scope VBA.Interaction.InputBox function; it resolves to your InputBox procedure, because VBAProject1.Module1.InputBox (assuming your VBA project and module name are respectively VBAProject1 and Module1) are always going to have priority over any other function defined in any other referenced type library - including the VBA standard library.
When VBA resolves member calls, it only looks at the identifier. If the parameters mismatch, it's not going to say "hmm ok then, not that one" and continue searching the global scope for more matches with a different signature - instead it blows up and says "I've found the procedure you're looking for, but I don't know what to do with these parameters".
If you change your signature to accept a String parameter, you get a recursive call:
Sub InputBox(ByVal msg As String)
That would compile and run... and soon blow up the call stack, because there's a hard limit on how deep the runtime call stack can go.
So one solution could be to properly qualify the InputBox call, so that the compiler knows exactly where to look for that member:
Link = VBA.Interaction.InputBox("give me some input")
Another solution could be to properly name your procedure so that its name starts with a verb, roughly describes what's going on, and doesn't collide with anything else in global scope:
Sub TestInputBox()
Another solution/work-around could be to use a similar function that happens to be available in the Excel object model, as QHarr suggested:
Link = Application.InputBox("give me some input")
This isn't the function you were calling before though, and that will only work in a VBA host that has an InputBox member on its Application class, whereas the VBA.Interaction.InputBox global function is defined in the VBA standard library and works in any VBA host.
A note about this:
If Link <> "" Then
This condition will be False, regardless of whether the user clicked OK or cancelled the dialog by "X-ing out". The InputBox function returns a null string pointer when it's cancelled, and an actual empty string when it's okayed with, well, an empty string input.
So if an empty string needs to be considered a valid input and you need to be able to tell it apart from a cancelled inputbox, you need to compare the string pointers:
If StrPtr(Link) <> 0 Then
This condition will only be False when the user explicitly cancelled, and will still evaluate to True if the user provided a legit empty string.
While looking for a way to test when a user cancels an InputBox, I stumbled across the StrPtr function. I believe it checks if a variable was ever assigned a value and returns zero if it was never assigned and some cryptic number if it was.
It seems like a useful function! I started with this code:
Dim myVar as string
myVar = InputBox("Enter something.")
MsgBox StrPtr(myVar)
The message box shows a zero if the user cancelled.
Fantastic! But then why do some insist that StrPtr never be used? I read it's unsupported. Why does that matter?
A good answer will explain benefits (beyond my example above) and risks of using the StrPtr function, possibly how you use (or don't use) it without giving an opinion as to whether everyone or no one should use it.
tldr; There's no real risk to using StrPtr like that, but there's not really a benefit either.
While it might look like you get a null pointer back from the InputBox call, you actually don't. Compare the result of StrPtr to VarPtr:
Sub Test()
Dim result As String
result = InputBox("Enter something.") 'Hit cancel
Debug.Print StrPtr(result) '0
Debug.Print VarPtr(result) 'Not 0.
End Sub
That's because InputBox is returning a Variant with a sub-type of VT_BSTR. This code demonstrates (note that I've declared result as a Variant so it doesn't get implicitly cast - more on this below):
Sub OtherTest()
Dim result As Variant
result = InputBox("Enter something.") 'Hit cancel
Debug.Print StrPtr(result) '0
Debug.Print VarPtr(result) 'Not 0.
Debug.Print VarType(result) '8 (VT_BSTR)
Debug.Print TypeName(result) 'String
End Sub
The reason why StrPtr returns 0 is because the return value of InputBox is actually malformed (I consider this a bug in the implementation). A BSTR is an automation type that prefixes the actual character array with the length of the string. This avoids one problem that a C-style null terminated string presents automation - you either have to pass the length of the string as a separate parameter or the caller won't know how large to size a buffer to receive it. The problem with the return value of InputBox is that the Variant that it's wrapped in contains a null pointer in the data area. Normally, this would contain the string pointer - the caller would dereference the pointer in the data area, get the size, create a buffer for it, and then read the N bytes following the length header. By passing a null pointer in the data area, InputBox relies on the calling code to check that the data type (VT_BSTR) actually matches what is in the data area (VT_EMPTY or VT_NULL).
Checking the result as a StrPtr is actually relying on that quirk of the function. When it's called on a Variant, it returns the pointer to the underlying string stored in the data area, and it offsets itself by the length prefix to make it compatible with library functions that require a C-string. That means the StrPtr has to perform a null pointer check on the data area, because it's not returning a pointer to the start of the actual data. Also, like any other VARTYPE that stores a pointer in the data area, it has to dereference twice. The reason VarPtr actually gives you a memory address is that it gives you the raw pointer to whatever variable you pass it (with the exception of arrays, but that's not really in scope here).
So... it's really no different than using Len. Len just returns the value in the header of the BSTR (no, it doesn't count characters at all), and it also needs a null test for the similar reason that StrPtr does. It makes the logical conclusion that a null pointer has zero length - this is because vbNullstring is a null pointer:
Debug.Print StrPtr(vbNullString) '<-- 0
That said, you're relying on buggy behavior in InputBox. If Microsoft were to fix the implementation (they won't), it would break your code (which is why they won't). But in general, it's a better idea to not rely on dodgy behavior like that. Unless you're looking to treat the user hitting "Cancel" differently than the user not typing anything and hitting "Enter", there really isn't much point in using StrPtr(result) = 0 in favor of the much clearer Len(result) = 0 or result = vbNullString. I'd assert that if you need to make that distinction, you should throw together your own UserForm and explicitly handle cancellation and data validation in your own dialog.
I find the accepted answer to be rather misleading, so I was compelled to post another one.
A good answer will explain benefits (beyond my example above) and risks of using the StrPtr function, possibly how you use (or don't use) it without giving an opinion as to whether everyone or no one should use it.
There are three "hidden" functions: VarPtr, StrPtr and ObjPtr.
VarPtr is used when you need to get the address of a variable (that is, the pointer to the variable).
StrPtr is used when you need to get the address of the text data of a string (that is, the BSTR, a pointer to the first Unicode character of the string).
ObjPtr is used when you need to get the address of an object (that is, the pointer to the object).
They are hidden because it may be unsafe to mess around with pointers.
But you cannot go completely without them.
So, when do you use them?
You use them when you need to do what they do.
You use VarPtr when your problem in hand is "I need to know the address of that variable" (e.g. because you want to pass that address to CopyMemory).
You use StrPtr when your problem in hand is "I need to know the address of the first character of my BSTR string" (e.g. because you want to pass it to an API function that accepts wide strings only, but if you simply declare the parameter As String, VB will convert the string into ANSI for you, so you have to pass StrPtr).
You use ObjPtrwhen your problem in hand is "I need to know the address of that object" (e.g. because you want to examine its vtable or manually check if the object address does or does not equal some value you knew previously).
These functions correctly do what they are supposed to do, and you should not be afraid to use them for their intended purpose.
If your task in hand is different, you probably should not be using them, but not out of fear that they will return a wrong value - they will not.
In a perfect world, you would stop at that conclusion. That is not always possible, unfortunately, and the InputBox situation you mention is one of the examples.
From what is outlined above, it would appear that you should not be using StrPtr to determine if Cancel was pressed in an InputBox. Realistically though, you don't have a choice.
VBA.InputBox returns a String. (This fact is incorrectly omitted from the current documentation making it look like it returns a Variant.) It is perfectly okay to pass a string to StrPtr.
However, it is not documented that InputBox returns a null pointer on a cancel. It is merely an observation. Even though realistically that behaviour will never change, theoretically it may in a future version of Office. But that observation is all you have; there is no documented return value for a cancel.
With this in mind, you make a decision on whether or not you are comfortable with using StrPtr on the InputBox result. If you are happy to take the very small risk of this behaviour changing in future and your app therefore breaking, you do use StrPtr, otherwise you switch to Application.InputBox that returns a Variant and is documented to return a False on a cancel.
But that decision will not be based on whether StrPtr is correct in what it tells you. It is. It is always safe to pass the String result of VBA.InputBox to it.
Fantastic! But then why do some insist that StrPtr never be used? I read it's unsupported. Why does that matter?
When someone insists that something should never be used, it's almost always wrong. Even GoTo has its correct uses.
I tired both using StrPtr and without using StrPtr. I tested my Sub with several examples. I got same results except in one occasion - When User inputs null value (nothing) and presses OK.
Precisely I tried these two:
Using StrPtr. "Invalid Number" was the result here
ElseIf StrPtr(Max_hours_string) = 0
MsgBox "Cancelled"
Else
MsgBox "Invalid Number"
Without Using StrPtr. "Cancelled" was the result here
ElseIf Max_hours_string = "" Then
MsgBox "Cancelled"
Else
MsgBox "Invalid Number"
This is my code.
Sub Input_Max_Hours_From_The_User()
'Two Common Error Cases are Covered:
'1. When using InputBox, you of course have no control over whether the user enters valid input.
' You should store user input into a string, and then make sure you have the right value.
'2. If the user clicks Cancel in the inputbox, the empty string is returned.
'Since the empty string can't be implicitly coerced to a double, an error is generated.
'It is the same thing that would happen if the user entered "Haughey" in the InputBox.
Dim Max_hours_string As String, Max_hours_double As Double
Max_hours_string = InputBox("Enter Maximum hours of any Shift")
If IsNumeric(Max_hours_string) Then
Max_hours_double = CDbl(Max_hours_string) 'CDbl converts an expression to double
Range("L6").Value = Max_hours_double
Range("L6").Interior.ColorIndex = 37
ElseIf StrPtr(Max_hours_string) = 0 Then 'ElseIf Max_hours_string = "" Then MsgBox "Cancelled" also works !
MsgBox "Cancelled"
Else
MsgBox "Invalid Number"
End If
End Sub
So I think it depends how important it is to handle the null value for you. All other test cases, including pressing Cancel, non-numerical inputs etc. give the same results. Hope this helps.
Read through this thread and ultimately ended up doing the following... which does exactly what I want.... If the user deletes the previous entry which is the default... and clicks ok.. it moves forward and deletes the back end data ( not shown ). If the user click's cancel, it exists the sub without doing anything. This is the ultimate objective and... this allows it to work as intended... Move forward unless cancel is clicked.
hth,
..bob
Dim str As String
If IsNull(Me.Note) = False Then
str = Me.Note
Else
str = "Enter Note Here"
End If
Dim cd As Integer
cd = Me.ContractDetailsID
str = InputBox("Please Enter Note", "NOTE", str)
If StrPtr(str) = 0 Then
Exit Sub 'user hit cancel
End If
In my opinion: Using StrPtr in order to identify if a value converts to 0 is extra code to write. if you use the following function like your example above
Sub woohoo()
Dim myVar As String
myVar = "hello"
myVar = InputBox("Enter something.")
'if Cancel is hit myVar will = "" instead of hello.
'MsgBox StrPtr(myVar) not needed
MsgBox myVar 'will show ""
End Sub
Now is this the only reason to not use StrPtr no not at all. The other issue you run into with using unsupported functions is that eventually they can break the application. Whether its a library issue or another programmer looking through your code and trying to find that function it just is not a good idea. This may not seem like a big deal if your script is only 100 lines long. But what about when it is thousands of lines long. If you have to look at this code 2 years down the road because something broke it would not be very fun to have to find this magical function that just does not work anymore and try to figure out what it did. Lastly especially in VBA you can get overflow errors. If StrPtr is used and it goes past the allocated space of your data type that you declared it's another unnecessary error.
Just my 2 cents but due to being able to use less code and the function being more stable without it I would not use it.
10+ years Excel Programmer.
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.