LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

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

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 .......

 

fixedimage.png

 

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

13 Comments
Proven Zealot

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.

Member

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

Regards,
Vijay S.
National Instruments
Member

@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

Active Participant

Editor bitness is easy enough:

 

Is64Bit.png

--
Chris Virgona
Proven Zealot

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

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Active Participant

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 Smiley Wink

--
Chris Virgona
Member

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.

Proven Zealot

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

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Proven Zealot

> 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).

Member

+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.