Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] Multi-threading and OleInitialize

The Ole support in SWT is apartment threaded only 
(COM.CLSCTX_INPROC_HANDLER | COM.CLSCTX_INPROC_SERVER).  That means you 
must make all Ole calls in the same thread as you created the ole control 
which in SWT is the UI thread.  DropTarget and DragSource must also be 
created in the UI thread.   In 3.0, I intend to restrict the API on 
OleClientSite, OleControlSite, DragSource and DropTarget to be allowed 
only in the UI thread.

When you say you are using SWT's COM API do you mean that you are making 
your own calls to internal COM classes?  This is not supported.  It is 
assumed that the first call to the internal COM class will be made through 
SWT public API and will occur in the UI thread.  If you are going to 
invalidate this assumption by calling the internal classes directly and 
from a non UI thread, then you will be required to call OleInitialize on 
the UI thread (and any other threads you wish to use COM on).





Erik Cassel <erik.cassel@xxxxxxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx
05/15/2003 12:51 PM
Please respond to platform-swt-dev

 
        To:     platform-swt-dev@xxxxxxxxxxx
        cc: 
        Subject:        [platform-swt-dev] Multi-threading and OleInitialize




I'm building an application that runs several UIs under different threads.
Some of these threads connect to automation servers (like Outlook) and
custom ActiveX controls using SWT's COM API. 

When creating a DropTarget in one of my threads I get:

"Cannot initialize Drop result = -2147221008"

-2147221008 turns out to be "CoInitialize not called" error. My workaround
is to call "org.eclipse.swt.internal.win32.OS.OleInitialize(0);" at the
beginning of the thread and "OS.OleUninitialize();" at the end.

I noticed that org.eclipse.swt.internal.ole.win32.COM has a static
"OS.OleInitialize(0)" call, so it looks like the first thread gets the
initialize and no other.

Is my solution safe? Is there a better way? Through trial and error I'm
avoiding SWTErrors by synching to display threads and praying I don't hit 
a
thread lock.

Comments, anybody?

My project may be rather ambitious, but so far SWT is working out very 
well!

-Erik

_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev





Back to the top