Does "Open Vi Reference" work differently in 8.5 if a string input is wired to vi path?

[billings11]

SO I was reading the upgrade notes to labview 8.5 and I noticed a change in the "Open VI Reference" function.  In 8.2 you can simply wire a string of the vi name to the vi path input of the function, and labview will open a reference to the vi already in memory.  But in 8.5 the relative paths have to be the same. 

So say I have a vi in memory called window.vi.  Its real path is C:\test\window.vi.  And let's say its already in memory and its reentrant so I can call it by vi server.  I used to be able to just pass a sting containing "window.vi" to the vi path input of "Open VI Reference."  I like to do that because I already know the vi is in memory, and it is a big pain to get all the relative paths right between developement and deployed executable.  This way I don't have to worry about getting dozens of relative paths right for a bunch of support vi's when I build an installer.  Does this mean if I upgrade to labview 8.5 I'll have to change this every single place I did it and then rebuild every installer to include support vi's with relative paths to the exe that are the same as their relative paths to the main vi in the development environment?

[tst]

I find it hard to believe to believe that this was changed, since this would break so many working programs. I think you probably misunderstood this. Can you supply an exact quote (preferably with a link)?

[jcase]

LabVIEW 8.5 did not change the behavior of the Open VI Reference function when passing in a string name. It will still look for a VI in memory with that name. If one is not found, an error is returned.

The note is talking about a change when opening a VI reference by path. However, when I tried this out in LabVIEW 8.5, the behavior did not seem to change. I filed a bug report to look into this issue.

When opening by path, LabVIEW will first look in memory for a VI with that path. If one is not found, LabVIEW will load the VI from disk.

The change was supposed to be that before completely loading a VI from disk, LabVIEW would get the fully qualified name. It would then look in memory to see if a VI with that name was already in memory. If there was one, an error should be returned since it is not the VI the user actually wanted.

Here is the Upgrade Note from LabVIEW 8.5 in case you are curious.

-----------------------------------------------------------------------------------

Open VI Reference Function

In LabVIEW 8.0.x and 8.2.x, if the name of the VI from the vi path input matches 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 path input matches the name of a VI in memory on that target but the paths differ, the Open VI Reference function returns an error.

-----------------------------------------------------------------------------------

[billings11]

Well thank god for that.  It is too bad the upgrade notes give no mention of how this impacts the executable environment, since it certainly seems like the executable the biggest and most likely part of the impact.  I bet you'll still have a ton of people with relative paths that are wrong in the installed executable but right in development environment.  Previously they would have worked even though the relative paths were wrong, but now you'll see errors.  By the way, what will happen if they have a relative path in the development environment but in the installed executable they compiled all their vi's into a single exe.  Will it error?  Do they have to rebuild with those vi's included as support files?

tst,

Check out the notes.  I don't know if there is enough there to understand or misunderstand, but I get nervous when they say stuff like this.

Open VI Reference Function

In LabVIEW 8.0.

x and 8.2.x, if the name of the VI from the vi path input

matches 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 path

input 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

[jcase]

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.

[billings11]

Weird.

Looks like the only other thing that affects me is all my precious class icons will have to get trimmed smaller.  Awww.

[billings11]

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