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.
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).
Ah OK.
Thanks for the info.
I should be fine. All the custom objects are transient. They are created, assigned to a local variable, have information extracted from them, and will be destroyed when the function (there are a whole bunch of them using it) completes.
Some of the extracted information (strings, bools and numerics) get stored in global variable. But never the object itself.
So I shouldn't run into leakage problems by the sound of it. :)
