Ok, I've got it.
Using CollectGarbage(); , even memory leakage problems seem to be avoided when storing in global module variables; I failed to achieve this in vbs.
Heh.
Is this to avoid the same gremlins I seem to have hit with doing this via VBScript?
Watching with interest. I have my VBScript one working now using old skool numeric loops rather than iterables on the returned object ....
Ok, I've got it.
Using CollectGarbage(); , even memory leakage problems seem to be avoided when storing in global module variables; I failed to achieve this in vbs.
Did you hit memory leaks when doing similar with VBScript extensions creating custom classes?
I'm using C# Script for a project at the moment, and I'm aware that the jScript engine (which is what the C# Script runs off I believe) does not auto-garbage-collect. So you need to invoke garbage collection manually from time to time, as you are doing.
But, as far as I'm aware, this isn't an issue with VBScript? Certainly not with normal script units anyway. Don't know about extensions once they're incorporated into the IDE. After you mentioned it, I did hammer my extension creating lots of instances of my custom class while watching the memory footprint of TC and it didn't increase dramatically ....
It depends.
Let's assume, You create objects in a vbs script extension using the helper function.
If You assign the created object to a local variable in a standard test script routine, the object will be released as soon as the routine is left (context destroyed). It will not be released before by statements like Set myVar = Nothing.
If You assign the created object to a global variable in a standard test module, the object will not be released automatically. It will also not be released by statements like Set myVar = Nothing. It will only be released when the script extension is deactivated or when TC is shut down (global context destroyed).
