TL; DR; You can Call it, but only explicitly from the VBA module.
Since the documentation related to @ Gary'sStudent ( see the agnostic version of the application here ) indicates, DoEvents is actually a Function not a Sub , and it will always return 0 in VBA. In unhosted Visual Basic (i.e. VB6), it returns the total number of open windows. My completely unfounded assumption about why it returns zero is that in VBA the top-level window of the process in which the code is executed does not belong to the code you are executing.
The function itself is located in the VBA.Interaction module, as you can see in the object browser:
However, you should note that you can use the DoEvents function, which is preceded by the Call keyword, but you need to explicitly reference the VBA assembly:
Sub Example() 'This is perfectly fine. Call VBA.DoEvents End Sub
Again, this is just an assumption, but I suspect that the reason is related to internal implementation. This usually calls the SwitchToThread function (which vbe7.dll imports). But the nature of the return value indicates an enumeration of the windows to which it is given, so to start, probably, you only need a VBA handle. Typelib says nothing about how it differs from any of the other functions of the interaction module (although there may be a flag that I missed somewhere):
[entry(598), helpcontext(0x000f7900)] short _stdcall DoEvents();
The nature of the Expected: Identifier compilation error indicates that inside the globally accessible VBA functions, there is something internal that “hides” DoEvents .
Final note: Call Foo syntax is completely redundant - all it does is explicitly discard the return value of the function. Not assigning a return value does the same.