Galaxiom, you QUIT the program but CLOSE what the program opened.
It is not the code project but the Office application thathas the file open. So you tell the Office App to Close the file, then you tell the Application to Quit. That is the correct exiting sequence.
When ChrisO did the experiment, do you know if he used local or global object variables?
Probably neither. I don't know the details of the test but I do know that ChrisO was more than enough knowledgeable to design a test for his hypothesis, that objects did not need to be set to Nothing before they go out of scope because this happens automatically. I expect that he used variables declared inside a procedure and ran that procedure in a loop.
I agree that objects should be cleaned up automatically when the pointer goes out of scope - but good programming practice suggests that you keep your code modular, passing in the data elements on which to operate, necessitating that the data elements you are going to use - the object pointers - DO NOT go out of scope so easily.
It appears to me that you are suggesting that it is a better practice to reuse a module variable and pass it to the procedure each time. So once declared it sits around in memory and might never be used again. You see going out of scope as as a weakness? I can't agree with that. The if the variable is relevant only in the context of a procedure then it aught to to have the scope of the that procedure.
My concern was/is that if you keep on creating new objects without first dereferencing the old ones, they are still in scope until your code exits.
Yes. An object created needs to be closed and the application managing needs to Quit. What I took from Chris is that the object pointer itself is automatically removed when it goes out of scope so setting it to Nothing is not required.
By the way, if you explicitly close the files opened by your app object, you really DON'T have to QUIT the app - you can just dereference it. See next discussion regarding "rundown."
Really? How soon does the application disappear when it has no files open? It is important because in some of my applications I keep a hidden Word instance running at module level and pass files to it as required. It is a worry it it could spontaneously Quit if left to itself for too long.
I accept that if the application quits, any files it has open will be released from memory. But not simply by dereferencing the app form the code project.
I believe that what happens is that setting the external app object to NOTHING will have the effect of a Close but its default closure behavior might not be what you wanted. You would lose data (since there is no connection to a session for the external application to ask the "Save" question) because you would probably get a Close/NoSave behavior.
I believe that what happens when the pointer is destroyed is that the code
loses its ability to communicate with the object. The object itself remains in memory which is why it should be told to Quit, ideally after commanding it to empty its Documents (or Workbooks etc) Collection.
I will clarify that I have PERSONALLY SEEN that a copy of Word persisted in my task list if I didn't remember to explicitly close what I opened.
Yes, Close what you Open before dereferencing it or it will persist. I see it happen regularly when code breaks during development and I have to kill it in Task Manager. However I am not convinced that setting the pointer to Nothing will destroy the external object itself. Even exiting the code project entirely doesn't destroy the Office app instance because, one created, it has a life of its own.