CoInitialize() ?  
Author Message
KLocal773





PostPosted: Sat Apr 03 00:19:38 CST 2004 Top

MFC >> CoInitialize() ?

Hi guys,

I read that you should use AfxOleInit() instead of CoInitialize() in an MFC
app, and that you don't need to call CoUninitialize(); is that right ? Will
I do any harm by using CoInitialize() and CoUninitialize() in my
InitInstance() and ExitInstance() respectively ? My apps are based on the
SDI non-doc-view architecture (they're kind of unconventional). I'm using
VC++ 6.0 (SP5). Thanks.

Visual Studio5  
 
 
Ed





PostPosted: Sat Apr 03 00:19:38 CST 2004 Top

MFC >> CoInitialize() ? AfxOleInit is preferred because you get an IMessageFilter implementation.
Also, the framework will automatically call CoUninitialize() (provided you
use AfxOleInit()).

Is there a particular reason why you don't want to use AfxOleInit?

Sincerely,
Ed Dore [MSFT]

This post is 'AS IS' with no warranties, and confers no rights.


 
 
Robert





PostPosted: Sat Apr 03 13:42:04 CST 2004 Top

MFC >> CoInitialize() ? Hi,

No, I have no particular reason not to use it except for the fact that I
don't see the CoUninitialize() being called but I'll trust MFC to call it
for me and rest assured. Thanks.


 
 
Perry





PostPosted: Sat Apr 03 17:39:26 CST 2004 Top

MFC >> CoInitialize() ? AfxOleInit() has additional support for COM (Ole) that using just the
standard CoInitialize() or CoInitializeEx() doesn't provide. Here is a
brief description of what AfxOleInit() does and when you should use it for
MFC apps.

Description:
Initializes the COM library on the current apartment, identifies the
concurrency model as single-thread apartment (STA), and enables additional
functionality which includes the following:

a.. Clipboard
a.. Drag and drop
a.. Object linking and embedding (OLE)
a.. In-place activation

The reason you should use AfxOleInit() instead of CoInitialize() for MFC is
because OLE objects are not thread safe and the underlying API call
OleInitialize() calls CoInitializeEx() with COINIT_APARTMENTTHREADED.

MFC does call the freeing routines as long as you call AfxOleTerm();

Perry



> Hi guys,
>
> I read that you should use AfxOleInit() instead of CoInitialize() in an
MFC
> app, and that you don't need to call CoUninitialize(); is that right ?
Will
> I do any harm by using CoInitialize() and CoUninitialize() in my
> InitInstance() and ExitInstance() respectively ? My apps are based on the
> SDI non-doc-view architecture (they're kind of unconventional). I'm using
> VC++ 6.0 (SP5). Thanks.
>
>


 
 
Robert





PostPosted: Sat Apr 03 22:11:57 CST 2004 Top

MFC >> CoInitialize() ? Thanks man,

So I have to call AfxOleTerm() also ? I didn't know that. I'll call
AfxOleInit() in InitInstance() and AfxOleTerm() in ExitInstance() of my
CWinApp-derived class, is that the way to do it ?

Now what about when I use CoCreateInstance(...) ? Do I need an MFC version
of that (if there even is one) ?

Take care,
Robert A.


 
 
Perry





PostPosted: Sun Apr 04 01:16:47 CST 2004 Top

MFC >> CoInitialize() ?


> Thanks man,
>
> So I have to call AfxOleTerm() also ? I didn't know that. I'll call
> AfxOleInit() in InitInstance() and AfxOleTerm() in ExitInstance() of my
> CWinApp-derived class, is that the way to do it ?

Sounds like a great place to do it. That's if you are using the
InitInstance() to init it.

>
> Now what about when I use CoCreateInstance(...) ? Do I need an MFC version
> of that (if there even is one) ?

There isn't one as far as I know that is MFC specific. As long as
CoInitialize() or CoInitializeEx() are called which OleInitialize() does
internally, you are good to go.

>
> Take care,
> Robert A.
>
>