PostUIMessageEx without Locking Up

[ShockHouse]

I came across some code that uses a LabVIEW OI with TestStand sequences for scripting tests. Each one of their tests involves performing a "Thread.PostUIMessageEx" and waiting for it to finish, indicating the test itself is done. The test is done inside of the UI Message event instead of in the VI called from TestStand.

The Thread.PostUIMessageEx locks up the User Interface whenever it is called, so they can't click Terminate or do anything on the screen because it is locked up 95% of the time. (Each test, insode of the UI Message Event may take 30s). I'm just looking for a bandaid fix, instead of changing the architecture if possible. Is there any way to make the Thread.PostUIMessageEx not lock up the UI. Changing from synchronous to asynchronous allows the VI to keep running, but still locks up the UI while the event is processing.

Please don't turn this thread into "how this is a bad design". That's not the point, and I'm aware it's not ideal. I'm just looking for a bandaid until it can be correctly overhauled if possible.

[ShockHouse]

Adding some more information.

In LabVIEW when you register for the "UIMessageEvent", the setting to disable Lock Panel is enabled, and you can't change it:

I tried instead to register the callback as "UserMessage" instead, because that allows you to uncheck that, but it still locks the panel even when unchecked. I'm assuming it still locks because UserMessage is really just an extension of UIMessage and that one force locks.

I do know LabVIEW has a way around this because if you put a breakpoint in the UIMessage callback, it no longer locks the panel for the life of the execution. But that can't be done programmatically. So that is all I've tried so far.

[angus2022]

Lock panel until handler cpmpletes

Does it mean that the panel is locked before the handler is completed, and will be automatically unlocked after completion?

Let me guess, did you set the synchronous parameter to true when calling Thread. PostUIMessageEx and register the UIMessage Event event to handle the message?

If that's the case, you can try two methods:

Method 1: Set the synchronous parameter of Thread. PostUIMessageEx to false

Method 2: Execute an operation at the completion of each UIMessage Event processing       (I don't understand Labview, C # code is like this)

if (msg.IsSynchronous)
{
   msg.Acknowledge();
}

           If you do not execute this, it will cause the test to be interrupted and will not continue to execute.

[ShockHouse]

Yeah, the panel gets locked until it's completed, and then automatically unlocked when it is done. I tried doing the Acknowledge to see if that could unlock it early, but it does nothing. Likewise, whether synchronous is true or false, the front panel is still locked up.

[angus2022]

Are you verifying through single step testing or continuous testing?

Can you try placing a breakpoint in UIMessage Event and then in the next step? (The current message has been processed, but the next message has not yet arrived)

In this case, is the panel unlocked?

[ShockHouse]

I've done both methods. And have done the breakpoint. No change.

I've giving up on trying to find a band-aid and am just redoing the architecture to not use UIMessages for running tests.