从Excel中的宏实例化Windows窗体会导致对话框“ Microsoft Excel正在等待另一个应用程序完成ole操作”

Question

Apologies for not being able to post any code examples (I've not yet been able to distill down to a small, reproducible codebase and the code I have is proprietary).

My situation is this: I have an Excel add-in, developed using Excel DNA, that pulls data from a REST web service that requires authentication. The add-in stores credentials on a per-session basis, but does not persist between instances of Excel. There also exists a macro that is exposed to the users that allow them to invoke the code in the add-in to pull the data from the web service.

The problem occurs in that if the user has not previously logged in, we pop up a Windows Form dialog asking for credentials. This works fine. After successful login, our logic commences (in one test, there's 6 concurrent requests) to pull the data from the web service. There's a little back and forth (request the data, it's unauthorized, login, request again, pull the data, etc). If the login happens programmatically (no Windows Form is presented or instantiated), everything works fine.

The problem I'm seeing is that when Windows Forms is involved, I'm seeing a 1 minute, 29 second delay (plus/minus a few fractions of a second) between the authorized request and getting the data back. This delay ends up resulting in an Excel dialog: "microsoft excel is waiting for another application to complete an ole action". The other wonky thing is that everything we have done has actually happened successfully, the user just gets this dialog and has to hit "OK" (and experience an unnecessary delay).

All indications are that the delays are occurring on the client side. If I completely remove the Windows Forms login dialog, we see no delays, and all actions complete with no prompts at all from excel.

On a whim, I completely removed the code to prompt with actual credentials and hardcoded our test account's credentials. And, it works fine. If I take that exact same code and just instantiate a blank Windows Form, ie new System.Windows.Forms.Form(); and do nothing with it, I get the exact same behavior in that part way through our requests, everything blocks for 1 minute, 29 seconds. Then, our request succeeds, but the client gets the aforementioned Excel dialog.

We also have the exact same functionality exposed through a Ribbon control that works fine, the only 2 differences are: 1. no macros involved, 2. we display a progress dialog while the work is going on.

We have verified that all UI elements are rendered/processed on the main Excel thread, and we do not do anything to interact with Excel, except on the main thread. No exceptions are raised (verified while running under the debugger with break on all exceptions thrown).

I thought we were doing something wrong, until I just instantiated a blank Windows Form (mind you - it was never even shown, just instantiated) and I could reproduce the behavior.

Has anyone seen this or know how to resolve?

Answer 1

This isn't an answer, but I don't think it'll fit as a comment. Also with the current info I'm not sure an answer is possible.

Yes, sure, the code is proprietary. However, you're going to have to show some of it or this isn't going to get anywhere. All I can do right now is offer some things to look at.

With add-ins it can be very difficult to know what thread you're actually on. Just before you create the login form, put these lin es:

    ApartmentState threadState = Thread.CurrentThread.GetApartmentState();
    if (threadState != ApartmentState.STA)
    {
        // put a break or some warning like console.Writeline(threadState);
    }

If it's not an STA thread then a Window Message pump cannot be instantiated - well, that's too strong: message pumps should only be on STA threads and although I think they can be on an MTA thread it will lead to problems.

If you have a reference to a UI element, something that inherits from Control, you can check whether it needs Invoking to change it:

if (control.InvokeRequired)
{
    // You're not on the GUI thread
}

If either of these fail, you're probably not on the thread you think.

Can you identify where the delay is? You say you're using a Windows Form to get the credentials. Can you debug the code and step through to see where the delay happens? Maybe step through from before Show()ing the form to when it's back on the main code path? Can you show the code where the delay occurs?

Just some things to try.