named constants for "open vi reference" options flags

[Labuser16383]

I do not like to hardwire constants to function calls like it is suggested in the manual page(sorry for the german citation)  for the said vi:

<< Optionen legt die Eigenschaften des über VI-Referenz angegebenen VIs fest (u. a. ob das VI asynchron aufgerufen wird). Die Voreinstellung lautet 0x0. Die Optionen werden durch Kombination folgender Options-Flags ausgewählt.

Options-Flag	Beschreibung
0x01	Änderungen aufzeichen—Mit dieser Options-Flag können Sie festlegen, dass bei Änderungen an einem VI durch den VI-Server ein Sternchen (*) im VI-Titel angezeigt werden soll. Damit LabVIEW die Veränderung aufzeichnet, muss sich das VI im Bearbeitungsmodus befinden.
0x02	Vorlagen zur Bearbeitung öffnen—Mit dieser Options-Flag wird die ursprüngliche *.vit-Datei geöffnet. Wenn Sie diese Options-Flag nicht auswählen, öffnet LabVIEW eine neue Instanz der VI-Vorlage. Die ursprüngliche *.vit-Datei ist von Änderungen an einem einzelnen Exemplar nicht betroffen. Auf Dateien, die keine Vorlagen sind, hat diese Options-Flag keinen Einfluss.
0x04	Benutzer zum Speichern auffordern—Mit dieser Options [...]

 >>

Therefore i came up with the question if possibly "vi.lib" could contain such named constants which could be combined (ored) with each other to give more meaningful parameters than such uninformative numbers.

Someone digged that deep into vi.lib?

[rolfk]

I don't think it does and there are several reasons. For one those constants would have to be Rings not Enums, as Enums would need to be consecutive (0,1,2,3,4..) and therefore can't be quadratic (0,1,2,4,8...) like is needed for flags. Also it would require explicit oring which most would hate to do as it requires one or more extra function palette accesses.

This is one area were text programming has an inherent advantage. Writing one or more constant names in the code with mathematic operators is about the same effort. In LabVIEW this involves automatically increasing effort, and occupies relatively large amounts of screen space.

[tst · Accepted solution]

I don't know of something like this in vi.lib either and I don't think it exists. This sounds like something which would work well as an XControl, but you can't place XControls on the BD and an XNode (which could do this) isn't the exact parallel of an XControl.

Another option is an Express VI, but then you don't get to see the configuration without going into the VI itself.

As Rolf says, you can use a ring, but rings aren't great for lists which could change (although deleting the ring and creating a new copy of it isn't very hard).

What I usually do is simply create a label on the constant and this is something you can do yourself easily enough and even have it in the palettes - create a group of VIs where each has a constant with the correct value and the label and then add them to your palettes as merge VIs. The result is that you will have this in the palettes, but you won't have any dependency on those VIs, so it will work on any computer after you place the constant.