Question

I have an app which creates a thread which communicate with the main UI via windows messages. It simply send the message to the main app thread and received the status.

That way I am displaying modal windows and do other things.

The problem is when I have to display a form which makes a call to a com+ server.
That way I get OLE error 8001010D: An outgoing call cannot be made since the application is dispatching an input synchronous call.

I think it happens because primary SendMessage is in use and com+ calls need windows messaging for its tasks.

Anyway, In delphi I cannot display the form from a thread, but how Could I workaround the problem … ?

Thanks

EDIT:

1. MAIN(UI) 2. A THREAD

A. A Thread(2) sends message to a main thread (1)
B. Main thread(1) receives the msg and before letting it come back to a thread
it displays the window.
C. The modal window in main thread wants to make a com+ call, the above error occurs.

---

1. What thread the modal window is in? 2. Which thread the COM call goes from? 3. Which thread the COM object was instantiated in? 4. Is the background thread initialized with an STA? 5. Is the modal form being shown from a SendMessage handler? – Roman R. 2 mins ago

   1. MAIN
   2. MAIN
   3. MAIN
   4. CoInitializeEx(nil, COINIT_MULTITHREADED);
   5. yes.

Answer 1

The problem cause comes from inability of COM to marshal an outgoing COM call while processing SendMessage request. The error which comes up is RPC_E_CANTCALLOUT_ININPUTSYNCCALL (0x8001010D), which you are referring to. I was under impression that this only applies to SendMessage calls which are a part of incoming interthread COM requests, however this might have been a false assumption.

Your typical workaround would be to replace your SendMessage with PostMessage followed by waiting for synchronization object, event or semaphore. This way your caller background thread does not hold messaging to synchronize the calls and waits autonomously, on the main thread the message being dispatched through regular message queue and eventually reaches the same handler.

As a bonus, you have an option to safely terminate the background thread. If currently it’s being locked by SendMessage API waiting for modal dialog, the suggested change would let you signal the synchronization object from the main thread and let it keep running, e.g. if you want to safely terminate it.

An alternate solution might be to call InSendMessage function and if true – defer modal UI, e.g. by again posting a message to self to pop the form up in another message handler later.