Difference between VBA.CBlah and CBlah

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 CLngPtr lights up like a christmas tree and looks just like any other keywords. Compare this with Abs, which is also a function but stays light blue, as if it was just an identifier.

This is a hint that CLngPtr is optimized by VBA compiler so it's actually inlining the method¹, which is why you get error if you try to use CLngPtr as an expression. However, a VBA.CLngPtr is 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, CLng or any conversion functions, and even Mid the statement (not function). There are several functions within VBA that 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.Print gets 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't Print without Debug.

---

1. When we refer to "inlinling" here, we are talking about what the VBA compiler is doing at lower level, below than what we see at the source code level. From the source code, C***() and VBA.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!) that CLngPtr()'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 with AddressOf -- any other function on the LHS will have the same syntax error, so it has nothing to do with the AddressOf and everything with the method being inlined.