How to make flattened strings intelligible

[Chickentree]

Hello,

I'm trying to make a VI that can call any VI with its file path, let the user edit its control input values and run it.

I tried using 'Variant to Flattened String' and 'Flattened String to Variant' functions.

The problem is that flattened strings are unintelligible to the user and any intelligible human string input will not be understood by the program because it has to be flattened.

I tried using 'Unflatten From String' but I get the same unintelligible strings.

What would be the best approach to solve this problem?

Thank you!

[GregFreeman]

What version of LabVIEW? You can use the start async call node if you are in, I believe, 2013 or later.

Edit: Looking at your code, why dont' you just run the VI...? Put a loop in it and let the user edit the controls directly on the front panel. What you are doing is way too convoluted.

[Chickentree]

I am using LabVIEW 2015.

If I call VIs like that, shouldn't it be strictly typed? I need some flexibility for connector pane configurations. Is there any way to programmaticaly generate different strict type constants for different VIs? But then, I still have to hard-code wires on the terminals.

"Edit: Looking at your code, why dont' you just run the VI...? Put a loop in it and let the user edit the controls directly on the front panel. What you are doing is way too convoluted."

The VI will be a part of a bigger application. It cannot let the user directly input values on the target VI's front panel.

[tst]

I would also suggest that this is probably a bad idea, because it doesn't sound like a good architecture for an actual app. Rather, it sounds like what you would do when you're developing in LV, so maybe that's what your end users should be doing. But maybe you really do need this, so let's crack on.

My first suggestion would be to use a subpanel. After the user selects the VI, you load the VI, put it in a subpanel, hide all the indicators and run the VI when the user presses a run button. That way, the user simply inputs the values directly on the FP.

A second option might be to use an existing framework for running VIs, like VI Tester or the Unit Test Framework. I have no real experience with them, so I don't know if that will work for you.

A third option would be to try going down the way you're going. You can use the flattened values, because as you see, they're not designed for readability, so you'll need something that converts the values. You can see examples of this type of conversion in the OpenG or MGI variant VIs, and what you will find is that it's hard coded - you need to have a specific case for every basic data type you support. There's special code to recursively handle arrays and clusters, but that just means the string the user builds will have to be in a very specific format.

[Chickentree]

I should've explained why I need this better.

If you have used TestStand, think of its code module settings pane. It can retrieve any VI's input and output names from its file path and let you set up input values before running the whole test.

Some parts of the VI I posted here are just for convenient development. For example, I wouldn't need the while loop waiting for the user to press the stop button in the real application.

The application should not show the selected VIs' front panels and user inputs must be all set up before running it.

I think I will have to look into the third option.

[tst]

---

@Chickentree wrote:

If you have used TestStand

---

I haven't.

---

@Chickentree wrote:

I think I will have to look into the third option.

---

Definitely. OpenG also already has a function for loading and saving all control values on a FP.

Note that if you're not showing the FP, LV might strip it if you build an EXE and then you can't set values on it. The easiest way which you can document to force LV to keep the FP is to create a property node for a control on the FP and put a comment next to it.

[Chickentree]

I just installed the OpenG toolkit. It has a lot of interesting functions. Thanks for the new discovery!

[Yamaeda]

Sounds like you want to do something similar to this:

/Y