Ok to call CoInitialize in the file dialogs?

[Robert Shearman]

Eric Pouech wrote:

> Michael Jung wrote:
>
>> Hi Eric,
>>
>> On Friday 11 November 2005 09:37, Eric Pouech wrote:
>>
>>> I ran into similar problems in shell32/shellole.c, function
>>> SHCoCreateInstance.
>>> Shouldn't when both bLoadFromShell32 and bLoadWithoutCOM are false call
>>> CoInitialize before CoCreateInstance (I got once a program needing 
>>> it) ?
>>
>>
>>
>> It's not obvious to me where we would call CoUninitialize in this 
>> case. As I understand it, we have to keep COM initialized until the 
>> created object is destroyed again. The short test program, which I've 
>> sent with the initial mail, seems to indicate that while COM is 
>> initialized inside SHBrowseForFolder, it's un-initialized again 
>> afterwards.
>>
>> Bye,
>
> I was more referring to the missing call to CoInitialize... I don't 
> think it's reasonable here to call CoUninitialize here ;-)


The point is that it is reasonable to call CoInitialize if you need it 
to use some objects and don't expose those objects to the caller, as 
long as you call CoUninitialize afterwards. However, it is bad to call 
CoInitialize without calling CoUninitialize because the caller may now 
want to call CoInitialize with a different threading model and this will 
fail, potentially causing errors if it tries to use objects from a 
different apartment. Not calling CoUninitialize is also bad because it 
can cause deadlocks on thread destruction in some cases if there are 
still objects lying around.
One further thing to note is that you can't call CoUninitialize in 
SHCoCreateInstance because if the returned object is a proxy then it 
will be automatically disconnected and hence become unusable.

-- 
Rob Shearman