Re-write LabVIEW code for Full UI and Simple UI

[CyGa]

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 !

[flaborde]

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?

[warren_scott]

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)

[flaborde]

Warren, Thanks a lot for your feedback! - Francisco

[CyGa]

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 😉

[warren_scott]

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.

[CyGa]

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.

[warren_scott]

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).

[Seth_K]

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.  

[Mr._Jim]

Old thread, but I second what Seth is saying about style. One of my shelved projects is cleaning up that code, and I honestly feel that NI should be doing this.

(Locals.BluntnessFilter = False)

I am not the kind of developer who just accepts  a codebase and rubber stamps it - I won't put my name on something unless it's up to my standards (or at least company style standards, which I am the author of). Globals, I can make an exception for.  ...but deprecated VI Server calls, sequence structures, VI documentation in properties never being set, (yeah it's on the diagram sometimes...), sloppy wiring, connector pain.. The TestStand vi.lib llb contents are pretty amateurish at best in my opinion.

This code is functional, but mediocre LabVIEW code at best. Please fix it - it's the year 2019 and it still has a layer of dust on it.

(P.S. I heart NI and NI developers. Please don't give me a thrashing when I come to Austin! Warren seemed unscathed, but maybe I won't fare as well )

[CyGa]

Hi Mr_Jim,

The idea still has a 'new' status since 2013...

But ! The latest API delivered by NI (since TS 2016 I guess) has been re-written. And it is much better. Not perfect yet, but much much better !

Maybe should take a look 😉

And see you at NI Week in a few days if you want to exchange about it 😉