Weird observation:
Normally when I want to save an address to a function in a variable, I do something like this:
Function getAddress(ByVal func As LongPtr) As LongPtr
getAddress = func
End Function
Sub printAddress()
Dim functionPointer As LongPtr
functionPointer = getAddress(AddressOf myFunc)
Debug.Print functionPointer
End Sub
However I just discovered I can use a 1-liner
functionPointer = VBA.CLngPtr(AddressOf myFunc)
while
functionPointer = CLngPtr(AddressOf myFunc)
... does not work and raises
Compile error:
Expected: expression
What's going on? The only difference as far as I'm aware is that CLngPtr is declared in the globals (class?) whereas VBA.CLngPtr is explicitly qualified, but I have no idea why that would lead to the observed behaviour (they both point to the same function don't they?)
This would be not very obvious if you used the default IDE settings which the keywords and identifiers aren't really set that differently. Here's how it looks when you use different colors:
You can see that
CLngPtrlights up like a christmas tree and looks just like any other keywords. Compare this withAbs, which is also a function but stays light blue, as if it was just an identifier.This is a hint that
CLngPtris optimized by VBA compiler so it's actually inlining the method1, which is why you get error if you try to useCLngPtras an expression. However, aVBA.CLngPtris a proper function and thus can be used as a part of an expression but with very slight performance penalty due to non-optimizing route.You would see the same thing with say,
CLngor any conversion functions, and evenMidthe statement (not function). There are several functions withinVBAthat may get inlined by the compiler and usually can be differed by whether they turn into keywords or not. Note also that the parenthesis are colored differently.Heck, even
Debug.Printgets the special treatment, too and if you are familiar with it, you may know that it's not exactly a class nor a module, yet you can'tPrintwithoutDebug.C***()andVBA.C***()are basically the same thing. However, the VBA compiler can and will try to optimize those bits, by internally rearranging the machine instructions for converting (or whatever the inlined function is doing). The effect of rearranging the instruction is that it might no longer be compatible in all contexts. In this case, I can imagine (but do not know for a fact!) thatCLngPtr()'s inlined instructions returns a value, rather than a reference, which is incompatible for a parameter declaration, which is why we get a syntax error when we try to use it as a parameter. Note this does not happen withAddressOf-- any other function on the LHS will have the same syntax error, so it has nothing to do with theAddressOfand everything with the method being inlined.