LabVIEW
How do I programmatically determine what version a VI was saved in?
Although LabVIEW seems to know what version it was previously in, (it shows this information when you close a VI without saving and it promts you to save, you can click 'Explain' and it says it was in a previous version and what that version was) I don't think you can get that previous version number through a property node or any other means.
One way you might be able to it would be to actually open the VI, then check the VI property "Modifications>VI Modifications Bitset" property. If the output of this property is zero, then no changes have been made to the VI, so that would indicate that it is saved in whatever version you are running the tool in. If this number is anything other than zero, then something in the VI has changed. Unfortuately, you w
on't know for sure what has changed. It could be recompiled due to a version change, or it may have found a sub-vi in a different place. You would then have to open the VI and look for yourself.
It's not exactly what you want, but it might get you close.
Ed
One way you might be able to it would be to actually open the VI, then check the VI property "Modifications>VI Modifications Bitset" property. If the output of this property is zero, then no changes have been made to the VI, so that would indicate that it is saved in whatever version you are running the tool in. If this number is anything other than zero, then something in the VI has changed. Unfortuately, you w
on't know for sure what has changed. It could be recompiled due to a version change, or it may have found a sub-vi in a different place. You would then have to open the VI and look for yourself.
It's not exactly what you want, but it might get you close.
Ed
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
Good thinking.
After a bit of experimenting, my best guess would be bits 4 and 5 of the number indicate a version change and recomile, and I think bit 4 is the one for a version change.
Maybe somebody at NI could verify/correct this, or at least point to some documentation on the mod bitset property.
After a bit of experimenting, my best guess would be bits 4 and 5 of the number indicate a version change and recomile, and I think bit 4 is the one for a version change.
Maybe somebody at NI could verify/correct this, or at least point to some documentation on the mod bitset property.
I am very surprised that the LabVIEW version of a VI cannot be reached with a simple propery node. This seems like a very desirable information parameter.
Just peeking inside a vi file, I found that a few bytes at offset 44 show a relatively strong correlation with LabVIEW version back to 6.1 on all VIs I have made. On some rare VIs picked up here on this board, the pattern does not match (my wild guess is either foreign version, student version, evaluation version, or similar, but who knows).
I have attached a demo (LabVIEW 7.0). Maybe some of you can get a few more measuring points to verify. Maybe I am way off with this idea. 😉
Just peeking inside a vi file, I found that a few bytes at offset 44 show a relatively strong correlation with LabVIEW version back to 6.1 on all VIs I have made. On some rare VIs picked up here on this board, the pattern does not match (my wild guess is either foreign version, student version, evaluation version, or similar, but who knows).
I have attached a demo (LabVIEW 7.0). Maybe some of you can get a few more measuring points to verify. Maybe I am way off with this idea. 😉
Thanks Feroz. Nice little tool.
Did versions before 7.0 have a different mod bitset, or can I use docmod descriptions.vi subvi to build a tool for 6.1 and earlier versions.
Ed
Did versions before 7.0 have a different mod bitset, or can I use docmod descriptions.vi subvi to build a tool for 6.1 and earlier versions.
Ed
altenbach wrote:
> I am very surprised that the LabVIEW version of a VI cannot be reached
> with a simple propery node. This seems like a very desirable
> information parameter.
No real surprise! When you open the VI refnum the VI is loaded and if
not in the current version it is converted and recompiled so it will
always have the same version as the LabVIEW version you are using.
> Just peeking inside a vi file, I found that a few bytes at offset 44
> show a relatively strong correlation with LabVIEW version back to 6.1
> on all VIs I have made. On some rare VIs picked up here on this board,
> the pattern does not match (my wild guess is either foreign version,
> student version, evaluation version, or similar, but who knows).
Knowing a little about
the LabVIEW resource file format, it is a highly
unreliable method. The differnt parts of LabVIEW VIs are saved in resource
lists similar to the way the Macintosh used to manage resources and offsets
into a file really tell nothing. It may be quite the same for a certain
LabVIEW version and newly created VIs, but it will change greately between
version and a lot of things can change the actual offsets.
Rolf Kalbermatter
> I am very surprised that the LabVIEW version of a VI cannot be reached
> with a simple propery node. This seems like a very desirable
> information parameter.
No real surprise! When you open the VI refnum the VI is loaded and if
not in the current version it is converted and recompiled so it will
always have the same version as the LabVIEW version you are using.
> Just peeking inside a vi file, I found that a few bytes at offset 44
> show a relatively strong correlation with LabVIEW version back to 6.1
> on all VIs I have made. On some rare VIs picked up here on this board,
> the pattern does not match (my wild guess is either foreign version,
> student version, evaluation version, or similar, but who knows).
Knowing a little about
the LabVIEW resource file format, it is a highly
unreliable method. The differnt parts of LabVIEW VIs are saved in resource
lists similar to the way the Macintosh used to manage resources and offsets
into a file really tell nothing. It may be quite the same for a certain
LabVIEW version and newly created VIs, but it will change greately between
version and a lot of things can change the actual offsets.
Rolf Kalbermatter
As mentioned by others, looking at the "current changes" in any VI just opened, it shows:
(a) The fact that it was converted, e.g.:
"VI converted from a different version of LabVIEW"
(b) What the previous version was, e.g.
"The VI, last saved with LabVIEW 6.1, has been converted to version 7.0."
Obviously, information (b) is readily available internally. For completeness, it should be available programmatically, exposed via a VI property. For me, it's a "surprise" that it's not. 😉
In can think of many uses for this, especially for code maintenance, e.g.:
-- A tool that quickly shows name, last saved version, revision number, etc. of all VIs in memory.
-- A tool that searches a file system for duplicates, then lists them as
above.
-- A masscompiler that does not touch VIs that are more than one versions older than the current release.
-- etc.
I agree that the method I showed is probably flawed, but it would be nice to be able to write a little tool such as this without the need for jumps through flaming hoops.
--------------------------
Back to the original question of this thread. For future projects, I would recommend to just arrange the VIs into folders where the name contains a clue to the LabVIEW version, e.g.
/../customer1/application2/6.1/...
Remember, since the customer has his own LabVIEW version in this particluar scenario, he might independently upgrade for reasons unrelated to your application.
(a) The fact that it was converted, e.g.:
"VI converted from a different version of LabVIEW"
(b) What the previous version was, e.g.
"The VI, last saved with LabVIEW 6.1, has been converted to version 7.0."
Obviously, information (b) is readily available internally. For completeness, it should be available programmatically, exposed via a VI property. For me, it's a "surprise" that it's not. 😉
In can think of many uses for this, especially for code maintenance, e.g.:
-- A tool that quickly shows name, last saved version, revision number, etc. of all VIs in memory.
-- A tool that searches a file system for duplicates, then lists them as
above.
-- A masscompiler that does not touch VIs that are more than one versions older than the current release.
-- etc.
I agree that the method I showed is probably flawed, but it would be nice to be able to write a little tool such as this without the need for jumps through flaming hoops.
--------------------------
Back to the original question of this thread. For future projects, I would recommend to just arrange the VIs into folders where the name contains a clue to the LabVIEW version, e.g.
/../customer1/application2/6.1/...
Remember, since the customer has his own LabVIEW version in this particluar scenario, he might independently upgrade for reasons unrelated to your application.
