NI TestStand Idea Exchange

About NI TestStand Idea Exchange

Do you have a feature idea for how to improve NI TestStand? Submit and vote on ideas now!

  1. Browse by label or search in the TestStand Idea Exchange to see if your idea has previously been submitted. If your idea exists sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea. Be sure to submit a separate post for each idea. Note: the TestStand Idea Exchange is not the appropriate forum to submit technical support questions.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see implemented!

The TestStand R&D team is committed to reviewing every idea submitted via the TestStand Idea Exchange. However, we cannot guarantee the implementation of any TestStand Idea Exchange submission until further documented.

Top Kudoed Authors
User Kudos Count
Showing results for 
Search instead for 
Did you mean: 

Re-write LabVIEW code for Full UI and Simple UI

Often working with Full Featured UI and Simple UI codes to create custom interfaces for TS, I noticed that the versions shipped with LV2012 are full of deprecated functions.

Also, most of their implementation go against good LV coding rules.


Re-writing them could be a great idea !


View Cyril Gambini's profile on LinkedIn
Could you be a little more specific on the issues that you found? I found some uses of the deprecated property FP.Open and the a call the method to get control value by control name, I have also found some connector panes that don't match the 4-2-2-4 and some of the VIs don't have an error wire wired through a case structure. Are there any that I am missing?
Active Participant

Here's my feedback on the UI:

I ran across a bunch of stuff running VI Analyzer (like 4224 connector panes, nice icons, error handling, etc) and saw some interesting stuff with DET (can't quite remember all of it -- could go back through SCC logs and figure it all out, but that really sucks because I can't revision / get history on individual files -- it's all just one llb in SCC -- but I know some was TestStand UI and some was LabVIEW vi.lib).

One thing that I needed to spend a bunch of time on is that the init/close of the UI has some utilities to remember the control locations at edit time and return them to those locations/sizes when the UI finishes.  That's great, but expanding that to support controls/indicators that I add to the UI was PAINFUL, and it would not take much for the out-of-the-box resize engine to take "anything" and work with it, and then adding my custom controls to the engine would be just appending them to the array and I'm done.

Another Idea -- a bunch of the UI extensions have some amount of "add a VI subpanel" nature.  How about building that into the full featured UI and show a end-to-end reference architecture.

Working with the dropdown menus -- it is really easy to just accept the TestStand default dropdown menu items for File/Edit/etc.  Using the built-in VI's to remove/disable elements from that list takes a bunch of extra coding. (example -- how do you let the user have the normal full featured UI but make sure they cannot select a step to "force Pass" in the runtime UI -- taking that out of the menu (or disabling) should be easier with the out-of-the-box VI's)


Warren, Thanks a lot for your feedback! - Francisco
Active Participant
Hi, Nothing to add to Warren post, perfect ! In fact, rewritting the API following standard LV rules, have a special attention on references handling, would be fine... But in that case it will require lot of work Smiley Wink

View Cyril Gambini's profile on LinkedIn
Active Participant

Actually, I would completely disagree with the comment about cleaning it up paying special attention to reference handling.  I can understand the initial yuck factor for someone first looking at the design and seeing a lot of global variables used for references, but after thinking about it for a long while and using it, I am completely in favor of how they designed the reference management structure (at least for the full featured UI design -- the only one I am familiar with).  Yes the LV guidelines say to avoid locals and globals, but I think this is one place that they are well suited, especially since they are used as a write-once-read-many storage and you don't end up with race condition problems.   If you've got a good idea for another architecture to use for the reference management, let's hear it out, but don't get scared of globals just because they are globals.

Active Participant

Hi Warren, i'm not talking about Globals here (i usually don't like them, but in that case they are pretty usefull...), I was more thinking about paying attention on closing references correctly to avoid memory leaks. In additition to clearly do something about Variant casting in Uimesage callbacks which also create memory leaks if don't use a specific function (found on a forum...) to cast them.


View Cyril Gambini's profile on LinkedIn
Active Participant

Totally agree with the closing reference issue -- I turned that set of problems into a learning exercise for DET and cleared up a bunch.  Unfortunately it's hard for me to unwind what exactly was done and which were my personal adds of dangling references and which were there from the reference architecture.  (see mini rant above regarding llb's and not being as easy with revision control and diff).


I'd like to add my vote to refactor the full featured UI to adhere to LabVIEW coding guidelines.  


While I can see an argument for globals being used for references with the write-once-read-many, if they are discouraged by NI as a blanket policy, then they probably shouldn't be showing up in example code.  As an alternative, what do you think about making a cluster with all the references, and housing that in a functional global?


The other things to fix are

  1. The stacked sequence in the beginning.  
  2. The group of wires coming out of the Init subVI that do nothing but go to the shutdown SubVI (These should be cleaned up into a cluster if they don't need to be split apart).  
  3. The lack of 4224 in the majority of the subVIs.
  4. The use of the llb file vs the lvlib.  Also, I found that there is one subVI that I can't manually move because it is password protected.