Synchronization of sequence execution with UIMessage handling

[mishaw]

We are using TestStand 4.0 with SequentialModel and custom Operator Interface.
Operator Interface provides UIMsg_UserMessageBase handler for displaying log messages.
When posting (asynchronous) significant number of messages from within test module, TestStand engine blocks sequence execution until handling all incoming messages.
For example, test module perform
"PostUIMessageEx(UIMsg_UserMessageBase, 0, "Message", 0, VARIANT_FALSE);" call 1000 times.
After test module code is completed execution, execution of next test is blocked for tens seconds until all posted messages are being displayed by Operator Interface.
As a result total time of sequence execution increased dramatically.

How this issue can be solved?

Thanks,

Misha

[EadieU]

Hi Misha,

If you post asynchronous UI messages faster than your OI is handling them, the messages are stored in a queue that is first-in, first-out (FIFO).  An execution ends when the EndExecution UI Message is handled. Because you are posting UI Messages asynchronously, the EndExecution UI Message is being stored in the queue. This is why you experience this behavior.

I have two suggestions for you:

1. Use synchronous messages. 
This will prevent the queue from growing.  The speed at which your messages are handled by the operator interface (OI) will be an effect of the OI's efficiency. 
You can learn more about asynchronous vs. synchronous messages in the TestStand help for the PostUIMessageEx:
http://zone.ni.com/reference/en-XX/help/370052G-01/tsapiref/reftopics/thread_postuimessageex_m/
This is the same Help documentation that came with the TestStand software. 


2. Post fewer messages
To quote the help file mentioned above in reference to the synchronous parameter, "If you pass False and post messages faster than the user interface processes messages, the number of messages in the queue the user interface must handle grows unbounded and floods the user interface with messages, which causes the user interface to become unresponsive."

Regards,

Mark E.
Applications Engineer
National Instruments