dvenkat
asked on
Destroying an automation enabled class from within
I have a CMdTarget derived automation enabled class (call it DocClass).
I want to provide a method (say "Close")to this automation class which
destroys itself.
How to do it?
"delete this" leads to assertion failure.
-----------
PS : My VB controller code reads like this:
sub Test()
Dim docs As DocCollection
Dim doc As DocClass
set DocCollection = Application.DocCollection
set doc = DocCollection.Item(1)
doc.Close '' I want this line to destroy "doc" object and
'' make it invalid object reference
'' HOW TO IMPLEMENT THIS???
End sub
I want to provide a method (say "Close")to this automation class which
destroys itself.
How to do it?
"delete this" leads to assertion failure.
-----------
PS : My VB controller code reads like this:
sub Test()
Dim docs As DocCollection
Dim doc As DocClass
set DocCollection = Application.DocCollection
set doc = DocCollection.Item(1)
doc.Close '' I want this line to destroy "doc" object and
'' make it invalid object reference
'' HOW TO IMPLEMENT THIS???
End sub
Should you not just release its refercence by doing a set Doc = nothing??
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Norbert,
Thanks for your answer.
My problem is more fundamental and is related to MFC code (not VB controller code). Actually I am integrating VB scripting engine to my application ('s object hierarchy).
This means, at run time when I create my scripting dialog, I instantiate VB scripting engine, create a COM object, and attach it to the VB scripting engine's name space (say with the name "Application", so that I can make reference to this object in my VB script and go from there.
However when I want to exit the scripting engine, scripting engine is NOT decrementing the reference count of this object (added to its name space). I do not know why (as such there is no need for you to explicitely delete automation objects (ActiveX engine does it for when the reference count =0).
Since the reference count is not getting decremented, even after my application exits, I have a ghost lingering! (You have to go to "running processess view" to kill it). By now you would have figured out my real problem: since the reference count is != 0, when I "close" the application, the ActiveX engine is really NOT closing the project! It just goes invisible.
I thought, doing "delete this" at destructor may help. But it is not helping. Perhaps I have design problem.
Anyway thanks for your effort and answer.
Thanks for your answer.
My problem is more fundamental and is related to MFC code (not VB controller code). Actually I am integrating VB scripting engine to my application ('s object hierarchy).
This means, at run time when I create my scripting dialog, I instantiate VB scripting engine, create a COM object, and attach it to the VB scripting engine's name space (say with the name "Application", so that I can make reference to this object in my VB script and go from there.
However when I want to exit the scripting engine, scripting engine is NOT decrementing the reference count of this object (added to its name space). I do not know why (as such there is no need for you to explicitely delete automation objects (ActiveX engine does it for when the reference count =0).
Since the reference count is not getting decremented, even after my application exits, I have a ghost lingering! (You have to go to "running processess view" to kill it). By now you would have figured out my real problem: since the reference count is != 0, when I "close" the application, the ActiveX engine is really NOT closing the project! It just goes invisible.
I thought, doing "delete this" at destructor may help. But it is not helping. Perhaps I have design problem.
Anyway thanks for your effort and answer.
Because the destuctor is not called when the Object is not released delete this can not help.
You Asked in your question for
doc.Close
did you try doc.Release() ?
You Asked in your question for
doc.Close
did you try doc.Release() ?
ASKER
In the MFC code, calling explicitely "OnFinalRelaease" before calling "delete" of this object created with "new" solves the problem.
Thanks
Thanks