File Version Info

[lgr1]

It took a call to NI to find a vi that would display the version information on the front panel of an executable. He sent me a vi that is found in vi.lib\Platform\fileVersionInfo.llb. I use the version information to control the version of the software that production is using in the automated test stand that I designed. It would be very helpful for this llb to be part of the function pallet.

[smercurio_fc]

see here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Palette-item-for-vi-lib/idi-p/1022250

[lgr1]

Permalink, What I am actually asking for is that fileVersionInfo.llb become part of the official pallet. Using a work around like coping it to my project directly can result in it not being compatible with future revisions of Labview.

[rgvdh@rdf]

Why are so many of the useful little things in LABview hidden and unsupported?

[AristosQueue (NI)]

> Why are so many of the useful little things in LABview hidden and unsupported?

Reason 1: Because we want to be able to change some of the internals over time, and making them part of the official supported code means we cannot break compatibility.

Reason 2: Something was added to solve a specific problem and it was tested for that one specific case but was never tested for the general whatever-someone-tries-to-do-with-it use cases.

Reason 3: We generally aim LV at a "you can write a VI to control your application." We don't focus on "you can write a VI to control our application (aka LV itself)." A lot of the hidden stuff is parts of the editor.

Reason 4: Sorry, reason 4 is private and requires a config token to unlock. 🙂

[AristosQueue (NI)]

> Using a work around like coping it to my project directly can result in it not being compatible with future revisions of Labview.

Yes. That is exactly why it isn't part of the supported stuff... we want to be able to change the file formatting, possibly dramatically, and we don't want to be breaking user VIs. If you're writing an editor extension, you should write it for one version of LV and then be prepared to modify it extensively for the next version if necessary. All of our internal extensions face that possibility.