09-05-2007 11:29 AM
09-05-2007 12:19 PM
09-05-2007 12:26 PM
09-05-2007 12:58 PM - edited 09-05-2007 12:58 PM
Open VI Reference Function
In LabVIEW 8.0.
x and 8.2.x, if the name of the VI from the vi path inputmatches the name of a VI in memory on that target, LabVIEW returns a
reference to the VI in memory and LabVIEW does not load the VI specified
in the
vi path input. In LabVIEW 8.5, if the name of the VI from the vi pathinput matches the name of a VI in memory on that target but the paths
differ, the Open VI Reference function returns an error.
Message Edited by billings11 on 09-05-2007 01:01 PM
09-05-2007 01:07 PM
The change in behavior is a little more subtle than just all relative paths. The change was if you open a VI reference by path, but a VI already exists in memory with the same name but from different path, an error should be returned by the Open VI Reference. This is a much smaller use case.
But like I said before, the change seems to have not made it into LabVIEW 8.5 even though the upgrade notes mentioned it.
09-05-2007 01:09 PM
Weird.
Looks like the only other thing that affects me is all my precious class icons will have to get trimmed smaller. Awww.
09-05-2007 02:33 PM - edited 09-05-2007 02:33 PM
jcase,
I know its not all relative paths, I'm just saying suppose you have an application that opens a vi reference to a vi already in memory by relative path. And suppose the developer even made the relative path right in the development environment. Then he builds an executable and installer and includes that vi in the executable. Now he is still calling out the relative path in code, but in the executable the relative path has changed so it will be wrong. In 8.2 he'll never know the path is wrong because labview will just load the vi from memory. He'll think it is totally legal to do this. But as soon as he upgrades to 8.5 he will get errors for each time he did this, and he'll have to go back and fix his code. Since relative path information is kind of tedious to keep consistent between the development environment and installed executable environment, I bet that kind of thing happens a lot. I wouldn't be suprised if a lot of people out there have executables that are calling out the relative path from their development environment which is actually wrong in the executable. It definitely sounds like this changes things to work more like it probably SHOULD work, but I bet you'll still see people with newly broken code. All those inconsistencies are going to be exposed in 8.5.... Well, they would have been exposed in 8.5 if the change had actually been made!
Message Edited by billings11 on 09-05-2007 02:42 PM