Prev: newbie: how to cast a callback function to DWORD_PTR
Next: htmlhelp - uuid.lib library unrecognized
From: KellyLynch on 15 Feb 2010 04:23
Language: Visual C++ 6.0; MFC app with CWinApp-based class
OS: WinXP


I use a COM component (http://www.emailarchitect.net/webapp/popcom/)
in MFC app. I release it BEFORE call of ExitInstance; in ExitInstance
I call CoUninitialize. This CoUninitialize hangs. If I call
CoUninitialize not from ExitInstance but right after the COM object is
released - no hangs.

All I know about this COM component is it uses asyncronous mode amd
uses sink interfaces for client notification. Partially it uses ATL's
method DispEventAdvise. My application has not its own cycles of
message processing - only standard MFC cycle in CWinApp.

The hang does not depend on what was used to initialize COM:
CoInitialize( NULL ) or CoInitializeEx(NULL, COINIT_APARTMENTTHREADED).
From: Alf P. Steinbach on 15 Feb 2010 04:40
* KellyLynch:
> Language: Visual C++ 6.0; MFC app with CWinApp-based class
> OS: WinXP
>
>
> I use a COM component (http://www.emailarchitect.net/webapp/popcom/)
> in MFC app. I release it BEFORE call of ExitInstance; in ExitInstance
> I call CoUninitialize. This CoUninitialize hangs. If I call
> CoUninitialize not from ExitInstance but right after the COM object is
> released - no hangs.
>
> All I know about this COM component is it uses asyncronous mode amd
> uses sink interfaces for client notification. Partially it uses ATL's
> method DispEventAdvise. My application has not its own cycles of
> message processing - only standard MFC cycle in CWinApp.
>
> The hang does not depend on what was used to initialize COM:
> CoInitialize( NULL ) or CoInitializeEx(NULL, COINIT_APARTMENTTHREADED).

I've had this problem long ago, and it turned out (but I never fixed the app
properly, using instead some other work-around) that initalizing COM "late",
relying on the fact that you can have nested init/uninit calls, was to blame.

Since you're using MFC that's perhaps unlikely, but anyway, try to put COM/OLE
initialization as about the first that ever happens in the app.



Cheers & hth (even though unlikely with MFC),

- Alf


PS: Try upgrading your compiler. Yes, 6.0 had the bestest IDE, DevStudio, but
that was long ago. You can download Visual Studio Express for free from MS.
From: KellyLynch on 16 Feb 2010 03:28
On 15 фев, 11:40, "Alf P. Steinbach" <al...(a)start.no> wrote:
> * KellyLynch:
>
>
>
> > Language: Visual C++ 6.0; MFC app with CWinApp-based class
> > OS: WinXP
>
> > I use a COM component (http://www.emailarchitect.net/webapp/popcom/)
> > in MFC app. I release it BEFORE call of  ExitInstance; in ExitInstance
> > I call CoUninitialize. This CoUninitialize hangs. If I call
> > CoUninitialize not from ExitInstance but right after the COM object is
> > released - no hangs.
>
> > All I know about this COM component is it uses asyncronous mode amd
> > uses sink interfaces for client notification. Partially it uses ATL's
> > method DispEventAdvise. My application has not its own cycles of
> > message processing - only standard MFC cycle in CWinApp.
>
> > The hang does not depend on what was used to initialize COM:
> > CoInitialize( NULL ) or CoInitializeEx(NULL, COINIT_APARTMENTTHREADED).
>
> I've had this problem long ago, and it turned out (but I never fixed the app
> properly, using instead some other work-around) that initalizing COM "late",
> relying on the fact that you can have nested init/uninit calls, was to blame.
>
> Since you're using MFC that's perhaps unlikely, but anyway, try to put COM/OLE
> initialization as about the first that ever happens in the app.
>
> Cheers & hth (even though unlikely with MFC),
>
> - Alf
>
> PS: Try upgrading your compiler. Yes, 6.0 had the bestest IDE, DevStudio, but
> that was long ago. You can download Visual Studio Express for free from MS.

The same problem was on Visual C++ 2005

 | 
Pages: 1
Prev: newbie: how to cast a callback function to DWORD_PTR
Next: htmlhelp - uuid.lib library unrecognized