Watched the video. One issue stood out. The difference between hard compile and pseudo-code compile is razor thin from the
compiler viewpoint but not even close from the
execution viewpoint. VBA does not produce executable code.
https://analystcave.com/vba-compiler-add-in-to-vb-net/
VBA pseudo-compiles code but since it is not Intel "86" family code, it cannot be executed in the strict sense of just putting the starting address in the hardware PC register (the ultimate GOTO). It can only be processed by a pseudo-code simulator, emulator, or interpreter depending on the specifics. (And yes, those three methods ARE different.) I don't claim to know which of those three options actually applies in the case of VBA, but speed tests clearly show that loops are not true-executed. They are pseudo-executed. This is the basis for many claims about the preference for running SQL vs. VBA, because at least SQL's underlying code is true-compiled. A recordset loop, though it has to do essentially a similar thing, isn't true-compiled.
The VBA execution environment is processing the instructions in sequence. If a hardware interrupt occurs, it occurs in the VBA processor's code and the address to which the interrupt returns would be inside the VBA processor, not the pseudo-code. It is interesting that as long as you don't leave the raw computational environment, you can parallel-process stuff like strings - probably because the string paradigms are re-entrant. I suspect this is because the O/S also uses the string library and thus it would HAVE to be re-entrant to be worth a damn. And I have no idea how it knows that you have pseudo-code as the target of your AddressOf in the CreateThread call. But apparently it does.
The video is absolutely correct that you can write true-compiled .DLL code to be RE-ENTRANT (thus able to be called from multiple threads in parallel). If you don't write it re-entrantly, you can trip over your own feet, usually due to the "improperly shared resource" issue. This ties in with a discussion I held a long time ago about whether VBA was truly object-oriented. You point out that if you diddle with an object, things go south quickly. That implies that the COM objects were not written re-entrantly and thus are not fully object-oriented either. I'm going out on a limb here to say that part of the problem is that you don't get a new copy of the code for NEW class object methods. If you did, the code would indeed be re-entrant. Instead, I think the Access environment shares the same compiled code among all instantiations of the same class. THIS IS A GUESS based on observed behavior!
It is equally interesting that you
can write recursive code in VBA as long as you only use locally defined variables inside the routine - because all of the local variables go on the program stack in a context block. Recursive code is necessarily also re-entrant.
By the way, the reason for having issues with your earlier code in a 2016 environment might be explained in this article:
https://docs.microsoft.com/en-us/of...64-bit-visual-basic-for-applications-overview
Something has changed between then and now, probably related to the difference between 32-bit and 64-bit code. Is there a chance that your original code was Ac2007, not Ac2010? Because it appears that the code compatibility change occurred with the release of Ac2010.