CVI GUI not responding during function call

[nlbauers]

I have a CVI GUI that contains two third party activex control. One of the buttons on a third party activex control calls a function that takes several seconds to return from the call. During the function call to the control, the control sits in a loop with continuous calls to DoEvents (which is I believe, the VB version of PerformSystemEvents). While waiting for this function to return, I get responses from all of the other controls on the calling third party activex control, all the controls on the other third party activex control, but the buttons I have added directly to my CVI GUI are not responding. The third party controls are single threaded controls, no multitreading is going on in the controls or the CVI applicati
on. Any ideas what the problem is here?

[bilalD]

Hello

The activex control will not process the CVI GUI events. While CVI waits for a function to return, its not processing any of its own events. Which is why if you spend too much time inside a callback in CVI, you need to add ProcessSystemEvents() or ProcessDrawEvents() to force CVI to process the message queue. I would suggest not waiting for the function to return inside of a callback, but instead use a threadpool function to schedule a thread where you can do the waiting. you can use the CmtScheduleThreadPoolFunction() function for this. This way, you wont be block the main UI thread that process the CVI GUI's messages.

I hope this helps

Bilal Durrani
NI

[nlbauers]

Hi Bilal,
Thanks for your reply. I understand your suggestion and I think it would be a viable way to go, however, it is not clear to me why the CVI application in not processing it's message queue. The activex control is making a call equivalent to PerformSystemEvents while it is waiting to return. I was not very clear in my previous message, let me restate the problem:

My CVI6 application calls a function named "Acquire" on a third party activex control, written with VB6. When I call Acquire, it takes several seconds to return. While inside the Acquire function, I wait in a Do While loop, which continuously calls DoEvents (the VB evquivalent of ProcessSystemEvents) until the function is finished and returns.

If I use the same activex control in a
VB6 app, when I call Acquire the application will process other events (callbacks in CVI) while it is waiting for Acquire to return, because I use DoEvent inside the Acquire function. This is the behavior I expect.

However, this is not the case in a CVI application. The callbacks for the buttons on the CVI app are not processed while waiting in the Acquire function, like they are in a VB app. Why would the VB app process the events, and the CVI app not process them? Is there a way to get a CVI application to work this way without multithreading?

Thanks for your time,
Neil

[bilalD]

CVI and VB have different ways of processing messages. Im assuming that using the activex control in VB 6 was working becasue DoEvents was processing all the VB events, the ones that belongs to the activex control and the one that beloned to the main app.

When you use the control in the CVI app, now DoEvents only processes the events of the activex control. While inside a callback, CVI does not process events. That is why to force it to process events inside a callback ( redraw a panel for example ), you must call ProcessDrawEvents ( if you just want to redraw the GUI )or ProcessSystemEvents. So its a matter of different message queues. And the message queues are different because CVI at one point used to be a platform independant compiler

I
hope this explains things

Bilal

[nlbauers]

Your assumption about the VB events at the beginning of your reply is correct. Thanks for taking the time to explain, I get it now. So no workaround available for this? I am familiar with what is called "subclassing" in VB where you replace the WinProc function and trap selected messages while passing the rest on to the original WinProc function. Anything similar to that available with CVI?

Thanks again,
Neil