Replace Numeric "options" with Ring on "Open VI Reference"

[shew82]

Curently, when we use the Open VI Reference node, there is a numeric "options" input for specifying how to open the reference. For example, 0x01 for "record modifications", 0x02 for "open templates for editing", and so on.

To my best knowledge, the theory here is that is makes it "easy" to combine options, e.g. 0x03 to "record modifications" and "open templates for editing". The problem I have with this method is that 90% of the time I cannot remember the number to go with the option(s) that I want - I end up opening Context Help->Detailed Help, etc.

An alternative way would be to copy the VISA Flush Buffer node: use a ring control for each of this input. that way you could just select the "record modifications" option, or, if you need multiple options, combine them with a OR or compound logic node (or even, take an array of these options as the input, allowing 0 or more options to be select). This to be would be much easier as we wouldnt have to keep on going to the context help.

Let's make it happen! 🙂

Shaun

[tst]

What would happen to existing code?

LV could probably detect a combination of flags and replace it with the equivalent code, but that doesn't account for values which are not constant. The easiest solution would probably be to still support the old values and create the ring when creating a new constant from the primitive.

[jcase]

I like the array approach better than requiring users to OR flags together.

In LabVIEW, flags obviously have the problem where you just need to know (probably from documentation) which number represents which flag. However, I think LV flags also have the problem where it is not obvious flags can be combined.

Another oddity with the flags is if the input is a ring control, when combining flags, you would pass in a value that is not in the ring. Picture this in C++ (I know it is not the same, but I think it gets the point across.)

enum MyFlags { noFlags = 0, flag1 = 1, flag2 = 2, flag3 = 4)

void Foo(MyFlags myFlags)

Foo (flag1 | flag2)  <-- flag1 | flag2 is not actually a member of the MyFlags enum since its value would be 3.

[Albert.Geven]

I also like the array approach, It's readable and you still see the elements.

[rgvdh@rdf]

How about a ring with all the possible combinations?

Whle it would be a bit annoying to have to scroll through 16 possibilities, it would be but good for readability - when you're done you have a constant that says what it does wired into the node.

This approach also has minimal effect on legacy code - old-style numeric constants will be coerced to the right member of the ring.

[AristosQueue (NI)]

What about this idea for a new control to use for the options?

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-Control-Listbox-Ring/idi-p/1005617

[shew82]

That control looks nice for UIs but I'm not quite sure how it would work for a block diagram constant - would it just end up coming back to the array of rings?

[AristosQueue (NI)]

> would it just end up coming back to the array of rings?

I was thinking more of a delimited list of currently selected values, with a single drop arrow that would let you check off all the options you wanted.

[shew82]

That would work 🙂

(that type of control could also be useful for other NI and third party API configuration options... still, it would presumably take noticably more development time than just replacing the teminal on that intrinsic

[Mads]

I vote for  rgvdh@rdf's ring of all possible combinations...No problem with legacy code.  Just do it