Labview Window events blocking external External Call Libraries

[kt.orlando.fl]

Labview Version: 9.0.1

Com Error Code:  0x8001010D

http://support.microsoft.com/kb/131056

I'm encountering a weird glitch which occurs any time the Labview vi Window is moved around (click/drag) at run time. It appears as if Labview is processing the the window events and holds a lock on a resource required for one of my external dlls. This particular dll is a c++ library with C exported functions. The dll goes through a COM layer. The first call fails and returns the error 0x8001010D, "An outgoing call cannot be made since the application is dispatching an input-synchronous call.” The link above is what I believe may be occuring, but i dont know what the work around would be. These same calls having always worked fine from a cvi c .exectuable or .uir. Below is a sample, the error occurs frequently, while inside a loop while-loop, where i'm querying the instrument continously.

[myle00]

I have one suggesion, you dlls are set to be callled from the UI thread, change it so that it can be called from any thread (see image). Maybe it will help.

[kt.orlando.fl]

I've tried the "Run in any Thread" before and it actually makes the .dll calls fail completely. It only works in Run in UI Thread.

[kt.orlando.fl]

Can someone try any call into a COM library and see if they get similar results. I am able to see this every time ... for example if the the top left menu of the vi window is selected at run time and the move menu is opened. This will cause the call into the external dll to fail.

[rolfk]

COM uses deep down in its belly the OLE mechanisme, and that has a legacy thing. OLE uses the applications main event queue to distribute events to the objects, and most anything in COM/OLE relies on a responsive application event queue. And this will be true in other applications than LabVIEW too. If you want to learn more you should read up about apartement threading, and all that stuff in MSDN, but I can guarantee you that things will most likely only get unclearer as more as you read. That whole threading stuff about COM/OLE is one big nightmare only a sick person can have thought of.

Window moving and resizing however will usually block that event queue, as the application goes into a tight tracking loop, and things like continous updating during these operations will cause Windows to do its own stuff too, that will render the event queue more or less locked.

It's one reason I avoid Activex components whenever possible, even if I have to walk around two extra blocks to do so. And that is with ActiveX components called through the LabVIEW ActiveX interface, which goes through a lot of jumps and hoops to avoid such issues. It's very doubtful that your DLL does even the most simple jumps and hoops but there is no way for LabVIEW to add that for you, as it is all hidden behind the functional interface of your DLL.

[kt.orlando.fl]

http://support.microsoft.com/kb/198996

I found an article with a Microsoft Bug, it appears to be exactly what i'm experiencing. These were the work arounds.

To work around this problem if the application is running Windows 95, Windows 98, or Windows NT 4.0, use one of the following methods:

• Allow outgoing COM calls to fail with RPC_E_CANTCALLOUT_ININPUTSYNCCALL
• Call InSendMessage before you make any outbound COM calls in response to posted window messages. If InSendMessage returns TRUE, do not attempt an outgoing COM call.

This would have to be done by Labview, no?

• Make outgoing COM calls on another thread.

I tried the "Run in any Thread "option in Labview this does not resolve the issue

• Prevent the taskbar from creating a button for the window. To do this, create the window with the WS_EX_TOOLWINDOW extended style, or create a hidden window, and make the hidden window the owner of the visible window.

Don't have the capability to block the user events, I would have to disable the menu bar on all the vi's calling into my COM libraries. Not a good solution.

[myle00]

I just want to add something about running in another thread. I'm reasonably assuming that the fact that you set it to run in another thread doesn't actually make it run in another thread. You have it in a single loop, so I don't think LabVIEW would run it in another thread.

If you want to be sure that it's running in another thread place the dll calls in a second loop and communicate between the loops with a queue. This will probably create two threads for the two loops. And a queue, I believe, doesn't copy data so it wouldn't be less efficient.

[rolfk]

I very much daubt that LabVIEW does any COM calls itself unless you use ActiveX components through it's Active X container or Automation functions.