Teststand Manager Controls in Code Modules

Question

  I am trying to understand how UI controls work in code modules called by TestStand steps.  I can pass a reference to an Application Manager (perhaps the application manager?) to my code module using RunState.engine.GetInternalOption(InternalOption_ApplicationManager).  Does the sequence editor have an application manager?  Or the engine?  Is this the same as the Application Manager control I put on the front panel of the code module?  What about SequenceViewManagers and ExecutionViewManagers?  Can I create those in my code modules to display sequences or executions?  Or can I somehow get those from the sequence editor/engine, or from the Application Manager?
I know that I just asked a lot of questions, but I guess what I am looking for is some general guidelines for using the manager controls in code modules.  This all came about by an attempt to display an Execution View Manager control in my code module.  Feel free to ignore the following description of my various attempts to get this to work.  This exercise helped me understand the managers a little bit more, but I'm still a little confused.
Suppose I want to create a custom step type for debugging to display the variables for the current sequence context on the front panel of a code module VI.  (LabVIEW 8.6, TestStand 4.1.)  In my code module, I call ExecutionViewMgr.ConnectVariables to connect to a VariableView control.  Where do I get my ExecutionView Mangager from?  I tried two methods:
1) create an ExecutionViewManager control; set the manager's current execution using ExecutionViewMgr.Execution (pass RunState.Execution from TestStand to the code module).
It seems like this should work, but when I run my sequence from the sequence editor, the ExecutionViewMgr.Execution property node returns error -17500.
When I run from a LabVIEW Operator Interface (using the LabVIEW environment, not the exe), I don't get an error.  But I must connect a list control using ExecutionViewMgr.ConnectExecutionList, and select the execution from the list when the code module is running.  Then I can see the variables when I select the execution in the list.  However, the execution display on the OI goes blank.  I can see either the variables on my code module or the execution on my OI, but not both simultaneously.  It appears that an execution cannot be attached to more than one manager at once (I guess that's reasonable).
2) pass the result of RunState.engine.GetInternalOption(InternalOption_ApplicationManager) to the code module; set the manager's current execution using ApplicationMgr.GetExecutionViewMgr() (pass RunState.Execution from TestStand to the code module, then as a parameter to GetExecutionViewMgr() ).
In this case, I would expect that there is no ExecutionView Manager associated with the execution when running from the sequence editor.  But the ApplicationMgr.GetExecutionViewMgr() function returns a non-Null reference.  ExecutionViewMgr.ConnectVariables() causes an error dialog to be displayed (from the function itself, not from TestStand), although it doesn't actually output an error (and the VariableView control remains blank).  The error is "Unable to connect Variables View control."  (See attachment.)
When I run from my LabVIEW OI, it works perfectly--I see the variables on my code module's UI, and the execution appears on the OI simultaneously.  I guess this makes sense since the TestStand engine is returning the Execution manager that was already created by the OI.
Attachments:
Error Dialog.PNG ‏20 KB

Answer 1

TestStand only allows a single ApplicationMgr per process, creating a second one will error. So the engine will always return the one in either the UI or the Sequence Editor. Events should be seen by both handlers. You have to be careful to ensure that your extra handler does not mess up the UI's handler if yours is called first, like preacknowledging a message. As far as setting up a handler in a code module, you should be able to. However, we have not fully tested this capability, so we cannot say that we fully support this because you might run into issues. In addition, using LabVIEW might present additional issues that might not be seen in other development environments like CVI and Visual Studio. Performing some functionality that can process messages in a COM callback can cause potential hang conditions, to the less you do in a callback the better when using LabVIEW. Keep in mind that you have to ensure that you unregister your handler if the code module returns to the calling execution and you no longer want the handler to be called.
Attempting to use a new TestStand UI control in a different thread than the UI thread is not recommended because we have done almost no testing on this use case because it is not done in typical UIs.
Now, for customers that want to create a nice GUI that includes serial number prompting, but still want to be able to work with the Sequence Editor, I suggest that you implement a behavior that works with a supporting GUI, but support an alternative when a non-supporing GUI is present.
For example, you could do the following:
1. The process model can send a custom UI message synchronously to the GUI to ask for a serial number. The custom message would contain a reference to a property that contains (a) a boolean to indicate that the UI will "respond" to the message, (b) a string for specifying the serial number, and (c) a notification object from the TestStand Synchronization Server.
2. When receiving the UI message, a supporting UI will set the boolean to True, duplicate the reference passed locally, and acknowledge the UI message.
3. When the UI message returns, the exectution will determine if the UI supports the message. If yes, the exectution will (a) wait on the notifcation (b) When the user enters a serial number, the GUI will set the string property and then pulse the notification, and release the reference to the properties passed via the UI message. (c) The execution will return from the notification wait, read the serial number, and continue execution.
If no, the execution will need to use the default process model prompting or custom prompting that you devise when using the Sequence Editor.
The process model could use a UI message to determine if the GUI is supportive of this mechanism once instead of with each serial number prompt, but you get the idea.
Scott Richardson
National Instruments