Hi CoolBlue
Sorry, it took me longer as I told in the PM.
Now, that seems to become a fulltime job - I'm not sure if I can summon up that time.
I studied your pic now for quite a while and wonder how serious you're about the reference of
raw
Sheets(1).Range("A1") and
raw
Sheet1.Range("A1")
Be aware that though basically it's the same object, the references or pointers may differ. Sheets(1) is an object of a spreadsheet relative to its position in the workbook whereas Sheet1 is a - you may say - static object within a workbook.
I don't know if it is the right thing to put it, but to explain it more visually:
For Sheets(1): Is assigned a pointer, which itself points to the object Sheet1. To say there are 2 pointers necessary.
Sheet1 instead, as it is the end of the line of objects, only needs 1 pointer.
So don't get confused, if the two cases show different pointers.
Quote:
|
I made a tool to parse the memory structure of these objects and I can show a map of what is going on in your Mod02_objRange module...
|
What you mean with this? You can't probably monitor the entire memory, can you?
I think the key would be to know about the structure of an object. Unfortunately the CombSite stops before he comes to this. On purpose? I can imagine, that the structure is quite difficult. Probably even containing references to various pointers, which all together only forming an object?
Quote:
|
Although its useful for investigating the memory structure, the range object is not a useful example for checking garbage collection since no object structures are created... there are only references to global Range Objects which are not part of VBA's garbage collection
|
I basically agree on this one. The objects exist in memory and those don't get destroyed as long the objects themselves are alive, all what matters: Do the references to these objects get destroyed, and that of course is the job the garbage collector has to perform. Now, in case you're right that the stack gets moved around all the time, it will be difficult if not impossible to keep track of these movements. But I hardly can imagine that this is the case. It would mean unnecessary efforts for systems to keep track of these movements for itself.
I rather imagine memory like a town, there are districts (which get assigned to a program as excel), within the district there are streets containing numbers (pointers) which hold the references. An inhabitant (value/object/whatsoever) either lives their (during runtime) or get moved out (by the garbage collector, or by setting it to nothing in case of objects)
That would lead us back to us establishing: A pointer (varPtr) contaning any other information as during runtime, allows the conclusion that references got destroyed and memory is freed.