This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(240, 30%, 33%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EM%3C/text%3E%3C/svg%3E)
Microsoft 365 Excel version 2403.
C# application (WPF on .Net 8) using excel COM interop ("automation") which adds a menu in the Excel application and setsup a click handler (in WPF).
All works normally just fine, but when debugging and say dwelling a couple of minutes (1.5 to be more specific) at a breakpoint in the click handler code, Excel pops up a Ok/Cancel dialogbox stating "Microsoft excel is waiting for another application to complete an OLE action".
if I continue my code with this box still not Ok'ed or Cancelled (which is quite easily happening), the next call to Excel, e.g. Microsoft.Office.Interop.Excel.Application.ScreenUpdating = false; this call throws a COMException (0x800AC472).
If the dialog was closed before proceeding handler code all is fine.
This seems to happen with "all" calls to Excel while dialogbox is open (Ok, I haven't tested with all calls of course, but some).
This upsets my debugging session and I would like Excel to not behave like this, at least something which could be compiled only when debug mode.
Anyone have some hints?
Any update to this issue? Have you tried removing Excel's message filter?
What you describe is ordinary behavior for a COM Server that is using a message filter to control concurrency.
Although I don't recommend doing this you could use VBA to call the CoRegisterMessageFilter function to remove Excel's filter which is responsible for putting up the dialog.
Thanks
I think I understand the idea, but it should/must be controlled by the WPF application I think (and only when WPF application is running in debug mode). Do you know how to achieve that?
If this is only for debugging why does it need to be controlled by the WPF application?
Create a VBA macro and run it in Excel.
I could for sure do that (just remember to remove the macro at release, the workbooks are tightly coupled to the WPF app).
I will for sure try and see how it works, do you have some more details of how to do this in vba?
Take a look at the answer in this SO thread - https://stackoverflow.com/questions/44288799/how-to-deal-with-microsoft-excel-is-waiting-for-another-application-to-complete
FYI, the reason I suggested using VBA is because the CoRegisterMessageFilter function must be called by the Excel process. Your WPF application cannot directly do this. VBA seemed to be the simplest way to have Excel call the function. Other options such as injecting code into Excel are both more complicated and more difficult to implement than a VBA macro.
Thanks for info
In fact I tried to "inject" code into Excel by using the Microsoft.Vbe.Interop (for other reasons than this thread is about), but it failed or I did not understand how to use it.
I will try the vba macro way of filtering messages though
I tried to call the CoRegisterMessageFilter as described and it worked (no popup), but if breakpoint on e.g. ecelApp.StatusBar = "some text" is continued after a few minutes (no popup), the call throws with 0x80010100 (RPC_E_SYS_CALL_FAILED)
None of the above is surprising. While removing Excel's message filter eliminated the troublesome dialog it is not a cure-all to allow Excel to wait for extended periods while your debugging session makes a COM client non-responsive. You already know the right answer to this problem--don't sit at a breakpoint in the debugger for a long time.
Read this for some additional insight into the cause of RPC_E_SYS_CALL_FAILED errors. In particular note the commentary about failure to pump messages -- What does it mean when my cross-thread COM call fails with RPC_E_SYS_CALL_FAILED?.
Thanks for your kind info.
Even if I do not understand all the details involved, what if the clickhandler really and legitimately takes a long time (more than about 1.5 minutes) to return?
Sure, this is a long time, but it shouldn't be up to MS to decide if it is actually too long and it would be beneficial to be able to adjust the timeout at least.
Do you know if MS has documented this behavior anywhere?
Any long-running operation that blocks message pumping for a short interval measured in seconds causes windows to identify the application as "Not Responding." So an in-process click handler that initiates such a long-running operation is problematic and should not be handled on the UI thread. The generally recommended approach is to off-load such long-running operations to a non-UI thread. There is no option in Windows to adjust the interval that is used to flag an application as not responding. You get to wait for the application to start pumping messages again or close it.
A cross-process COM call that doesn't complete presents a similar problem. By design, the application has the responsibility to respond in a timely manner. Without the message filter or a timeout COM would need to be clairvoyant. How would it know if the call will ever return? Should it wait forever? The message filter dialogs are intended to provide feedback to the users about such a situation.
Removing the message filter dialogs was your stated objective. I've answered your question and advised you how to remove the dialogs.
In any event, you can provide Feedback to Microsoft about your concerns and suggestions.
Thanks a lot again for your thorough explanation,
You have been very patient :)
Actually it didn't strike me that this timeout is driven by Windows, I thought it is an Excel feature.
Anyway, In my case (cross process) some handlers will take quite some time, perhaps even more than a couple of minutes, if so I will definitely offload most of the work in a Task and return fast to Excel.
My "problem" is (I believe) only while debugging when execution is stopped.
I simply have to live with it!