Ok to call CoInitialize in the file dialogs?
Robert Shearman
rob at codeweavers.com
Tue Nov 8 12:59:24 CST 2005
Michael Jung wrote:
>Hi all,
>
>Some shell namespace extensions only work if COM is initialized (For instance
>the brand-new shell instance objects ;) Go download the free (as in beer)
>Shell Object Editor from www.tropictech.de if you want to try them.). On
>WinXP those work without the application calling CoInitialize in
>SHBrowseForFolder and in the file dialogs. I assume this means there is a
>CoInitialize/CoUninitialize pair guarding SHBrowseForFolder.
>
>For the attached browse.c test program (meant to be compiled with borland's
>free compiler - sorry) on can browse into shell instance objects on winxp,
>but the call to GetDisplayNameOf fails with CO_E_NOTINITIALIZED. This means
>COM is initialized inside SHBrowseForFolder, but un-initialized after the
>call returns. If you remove the '//' in front of the CoInitialize call and
>compile again, GetDisplayNameOf succeeds.
>
>On wine, you can't currently browse into shell instance objects, if COM is not
>initialized. If you add CoInitialize/CoUninitialize to SHBrowseForFolder (see
>attached patch), it exhibits the same behaviour as winxp.
>
>How expensive is COM un-/initialization?
>
It depends on the threading model you specify. Apartment threading is
more expensive than multi-threaded because it involves the creation of a
window, but both are fairly cheap (although I haven't got any numbers to
back this up). It is even cheaper if the thread has already initialized COM.
>Any objections against adding
>CoInitialize/CoUnitialize to SHBrowseForFolder and the file dialogs?
>
>
The only objection is that in general it is bad to force a threading
model and that the caller should be the one specifying it. However, if
this is what native shell32 does then we should also do it.
--
Rob Shearman
More information about the wine-devel
mailing list