Re: IXMLDOMDocumentPtr instance destruction
On 23 May 2006 11:22:49 -0700, "sandy" <srpasham@gmail.com> wrote:
Doug thanks for your reply.
I have a MFC extension dll where I am creating this DOM instance. This
dll is loaded OnClick event of a button. When I click a different
button I am using a ApplicationDestroy function to destroy this dll
window.
CJobEditorClient::ApplicationDestroy(void)
{
if(m_pJobEditorDlg->m_hWnd != NULL)
{
m_pJobEditorDlg->ShowWindow(SW_HIDE);
m_pJobEditorDlg->DestroyWindow();
m_pJobEditorDlg->m_hWnd = NULL;
}
//m_pJobEditorDlg->ShowWindow(SW_HIDE);
//pLotDlg->DestroyWindow();
return TRUE;
}
If this is a modal dialog, you should use EndDialog. If modeless, this
should be fine, though the SW_HIDE is redundant. In either case, you do not
need to set the m_hWnd member to NULL, because MFC manages that for CWnd
and classes derived from it.
From my understanding, after this function gets executed the DOM
instance needs to be destroyed and decrement the handle count. But in
my case the handle count doesnt gets decremented.it still shows the
same count 255
By "handle count", you're still talking about what you observe in Task
Manager, right? If so, I wouldn't worry about it unless it grows each and
every time you create and destroy a DOM instance.
I have even modified the CJobXMLParser destructor
CJobXMLParser::~CJobXMLParser()
{
m_plDomDocument.Release();
delete m_plDomDocument;
m_pDocRoot.Release();
delete m_pDocRoot;
}
Because you are using the dot operator to call member functions, those
objects cannot be pointers, and those deletes cannot be right. I suspect
the code compiles only because there is a conversion operator that returns
a pointer. So get rid of the deletes, and for that matter, the Release
calls, too, because they should be redundant. You can verify by tracing the
code in the debugger.
Here is what the macros do
#define BEGIN_BLOCK do{
#define END_BLOCK }while(0);
#define LEAVE_BLOCK break;
Hope I am not creating any confusion.
FWIW, I believe most people would say that macros such as the above should
not be used, because everyone does (or would do) them differently, so an
outsider always has to ask what they mean. IOW, don't use the preprocessor
to create your own little language.
--
Doug Harrison
Visual C++ MVP