Using Maps As A Better Way To Pass Command Line Arguments

So for those who don’t know, LabVIEW 2019 incorporates some new datatypes: Sets and maps. Piotr Kruczkowsk has been posting a bunch of possible use cases on Twitter. You can see them here. Peter has inspired me to come up with one of my own.

The problem with CLI arguments in LabVIEW

The App.Args Property just returns an array of strings

I was recently working on some Continuous Integration and I was launching exes from the command line. It reminded me of the shortcomings of LabVIEW. Currently, to get the command line arguments in a built executable, you use a property node and get back simply an array of strings. Anything after the name of the exe is split into an array based on whitespace.

This presents a few problems, such as

  • The arguments must be in order, and the end user has to remember what order.
  • The arguments are unlabelled, which makes it really hard to read the calling script.
  • It is hard to pass multiple values for an argument. What if for example, you want to pass in multiple filenames? Well, you could make it the last argument. Pull off the others and what’s left are filenames. But what if you had 2 arguments that required values?
  • It in hard to pass optional arguments. Again you could make it the last argument, but what if you had multiple optional arguments? or another argument that required multiple values?

Looking to LabVIEWCLI for an answer

Because I was doing a lot of Continuous Integration work, I was using the LabVIEW CLI a little bit. I noticed that LabVIEW CLI took parameters in more of a linux style using a -argument value syntax. It immediately made me question if that could be done in a regular LabVIEW exe.

Maps to the rescue

Piotr’s posts inspired me, so a I wrote a little vi to take CLI arguments in a -argument value syntax and convert then into a map.

I also wrote a vim similar to the SetDefault() function for Python dictionaries. It sets a default for the key if it doesn’t exist. if it does exist it just returns the existing value.

Here is a snippet of my set Default Method

Testing

I built an executable to test it all out. It simply converts the CLI arguments into a map, sets a default value for the option argument and then throws a dialog which shows the keys and values in the map. To do that I used Piotr’s Set and Map Helper Package.

This was the test vi that I built into an executable.

I tried it first without the optional argument. Note that option is set to A.

Without option argument defined. Note how easy it is to read and tell what each argument is.
Results without option defined. Note Option defaults to A.
Here I changed the order and explicitly set option to B
Note option is now set to B

If you would like to learn more about how to use advanced features like Sets and Maps to make your code simpler and more readable, set up an appointment and let’s talk about it!

Leave a Reply

Your email address will not be published. Required fields are marked *

*