Property to get LabView Editor bitness 32bit / 64bit and patch level

[Xite]

We need the additional properties of the used LabView Editor:

bitness: 32 or 64 bit

ServicePack Number: 1,2,3 ....

Patch Version: f1,f2,f3 .......

So, what i like to have is, that i can get the above listed properties from the currently running LabView Editor, programmatically!

See also forum discussion for the problem:

programmatically get Labview Editor bit Version

[AristosQueue (NI)]

The VI doesn't store patch -- patch doesn't change the version number of LabVIEW and does not change the information of a VI. That's why any patch can't modify the load/save formatting.

Service Pack you already have -- that's in the version number.

Bitness is something that some but not all VIs store. A source-only VI doesn't store bitness. But for those that do have a compiled code segment, we could dig up that information.

[VGA_CD-ROM]

Not exactly the same, but I have a tangentially-related idea to get LV Editor information from built EXEs (and maybe DLLs?)

[Xite]

@AristosQueue +AristosQueue

The idea is not about the VI it is about the editor!

We seperate source from binary.

Version Number is cryptic, knowbody understand, i want clear identifiers. Also Version Number do not change between 32bit Editor and 64bit Editor.

The Editor must provide this information so that we are able to make decisions on that at our build process and revision controll process

[fabric]

Editor bitness is easy enough:

[Norbert_B]

Nice remark, fabric, but sadly doesn't help. It states the bitness of the OS, not of the LV editor you are using.....

In your example, both LV 32bit and 64bit would run with "True" when running on a 64bit OS (which is naturally required for LV 64bit, but not for the 32bit!).

Norbert

[fabric]

Norbert: On my machine that code snippet returns the *editor* bitness correctly. It returns false when run from the LV2012 32-bit IDE on a 64-bit machine.

Did you try it? Am I missing something??

EDIT: The LV help seems to agree with me too 

[Xite]

I tested it with LabView 2014 and there it seems to work as well. Thank you Fabric for your input.

Nevertheless, i like to have the editor properties at one place, with one function.

[Norbert_B]

Ah, ok, i see what i did wrong: I failed to create the TARGET_TYPE==32 case. I somehow assumed that, in case that the case '==64' isn't true, the disable would remove the TRUE constant hence leaving "an emtpy tunnel" which should result in a FALSE. Obviously, the Conditional Disable structure doesn't work like that.

Lesson learned:

Never place a Conditional Disable structure with only a single case. Implement the alternative as well (aka. DEFAULT).

Norbert

[AristosQueue (NI)]

> The idea is not about the VI it is about the editor!

The picture you posted is about getting information from a VI on disk about which version it was last saved with. That's why it takes a VI path as an input. I assumed that meant you wanted the bitness, etc., that the VI was last saved with. If you want the properties of the editor in general, they do not belong on that method.

If you're using that method currently to get the version of the editor, you should stop. That will give you the version number of the editor used to edit that VI, NOT the version of the editor you are currently running (unless you're creating a VI, saving it, and then calling that method).

[Xite]

+AristosQueue you are absolut right. Thanks for making this clear. Unfortunatly i didn't found the possiblity to change the idea.

So, what i like to have is, that i can get the above listed properties from the currently running LabView Editor, programmatically!

If NI have the time, it can implement it also for the VI, this can also be very helpfull.