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.