From: Drew on 16 Feb 2010 13:59 VS2008 SP1. WinXP x64 SP2. Compiled as 32-bit. I'm using the feature pack to update my GUI. When I close the app, my CMDIFrameWndEx derived class's destructor is not being called leaving a zombie process still running. What could be the explanation? Thanks, Drew
From: Ajay Kalra on 16 Feb 2010 19:17 On Feb 16, 1:59 pm, "Drew" <d...(a)dam.com> wrote: > VS2008 SP1. WinXP x64 SP2. Compiled as 32-bit. > I'm using the feature pack to update my GUI. When I close the app, my > CMDIFrameWndEx derived class's destructor is not being called leaving a > zombie process still running. What could be the explanation? > > Thanks, > Drew Does your app support automation/COM where a possible ref count on your frame is not being decremented? -- Ajay
From: Drew on 18 Feb 2010 17:43 Ajay, Yes, it does support automation/COM using ATL but I'm not sure I understand your comment about the "ref count on your frame". The frame, which I'm reading as "MDIFrameWndEx derived class" is not a COM object in and of itself unless you are referring to the global CAtlMfcModule::_Module. I have code that only calls _Module.RegisterClassObjects() and CoRevokeClassObject() only if the app was instantiated as a COM server. Do I have to do something special with this variable in this case? My problem occurs just by opening my app and then just closing it immediately. Thanks, Drew "Ajay Kalra" <ajaykalra(a)yahoo.com> wrote in message news:5ca8d95f-18ad-4596-86b8-cd6678be0011(a)z19g2000yqk.googlegroups.com... On Feb 16, 1:59 pm, "Drew" <d...(a)dam.com> wrote: > VS2008 SP1. WinXP x64 SP2. Compiled as 32-bit. > I'm using the feature pack to update my GUI. When I close the app, my > CMDIFrameWndEx derived class's destructor is not being called leaving a > zombie process still running. What could be the explanation? > > Thanks, > Drew Does your app support automation/COM where a possible ref count on your frame is not being decremented? -- Ajay
From: John H. on 18 Feb 2010 19:10 On Feb 16, 12:59 pm, "Drew" <d...(a)dam.com> wrote: > When I close the app, my > CMDIFrameWndEx derived class's destructor is not being called Are you creating the object on the heap? If so, a delete needs to be done in order for the destructor to be called. If you are depending on the framework to delete for you, it might not work as you wish: CMDIFrameWndEx's destructor is not virtual. For example if some MFC code has an CMDIFrameWndEx * that points to the derived object you made, and it does a delete on that pointer, only CMDIFrameWndEx destructor will be called, not your derived class version. You might be able get things to cleanup properly by doing some special handling in an override of OnClose, DestroyWindow, or PostNcDestroy.
From: Joseph M. Newcomer on 20 Feb 2010 01:16 Actually, it is the reference count for the app. If you support automation, does this error occur when you are *using* automation, or does it occur if you just open-and-close. The feature pack is known to have several bugs; I would not be surprised if this is one of them; that it *should* have deleted it but failed to. And there's yet another issue: certain cleanups, such as those done on static variables initialized by initializers, happen correctly, but only AFTER the program exits, and the lost storage errors are issued BEFORE the static destructors. I've not used the feature pack, but check around to see if this is a reported bug. joe On Thu, 18 Feb 2010 16:43:19 -0600, "Drew" <dam(a)dam.com> wrote: > >Ajay, > >Yes, it does support automation/COM using ATL but I'm not sure I understand >your comment about the "ref count on your frame". The frame, which I'm >reading as "MDIFrameWndEx derived class" is not a COM object in and of >itself unless you are referring to the global CAtlMfcModule::_Module. I have >code that only calls _Module.RegisterClassObjects() and >CoRevokeClassObject() only if the app was instantiated as a COM server. Do I >have to do something special with this variable in this case? My problem >occurs just by opening my app and then just closing it immediately. > >Thanks, >Drew > >"Ajay Kalra" <ajaykalra(a)yahoo.com> wrote in message >news:5ca8d95f-18ad-4596-86b8-cd6678be0011(a)z19g2000yqk.googlegroups.com... >On Feb 16, 1:59 pm, "Drew" <d...(a)dam.com> wrote: >> VS2008 SP1. WinXP x64 SP2. Compiled as 32-bit. >> I'm using the feature pack to update my GUI. When I close the app, my >> CMDIFrameWndEx derived class's destructor is not being called leaving a >> zombie process still running. What could be the explanation? >> >> Thanks, >> Drew > >Does your app support automation/COM where a possible ref count on >your frame is not being decremented? Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
|
Pages: 1 Prev: show Image with CImage - Debug assertion failed Next: DialogBox not modal, why? |