Name conflicts using VIs for override

[Abdullah R]

QUOTE (TobyD @ Jan 22 2009, 01:48 PM)

Totally off topic...but I think I remember Stephen saying once that if his activity on LAVA suddenly increased it was usually a good indicator that all of his work for the next release of LabVIEW was complete and he had a bit of time before work on the next release had to begin. As I read through this thread I was noticing that you've been posting a lot today Stephen. :ninja:

Great now you made him not post anything. Thank TobyD...j/k :laugh:

[Aristos Queue]

LV8.5.1 is free for anyone on the SSP, which was sold bundled with all copies of LV8.5, so you definitely had it at one time. So as long as your company has kept your subscription up-to-date, you should have CDs for it somewhere. The ni.com SSP download site *might* still have 8.5.1 posted -- you'd have to check.

[Eugen Graf]

Now, having said that, I am sick and tired of this behavior, and I will seriously contemplate doing everything I can to hold the LV CD from being shipped to customers if the next version of LabVIEW doesn't allow multiple VIs of the same name to be stored in the EXE. The feature/bug fix (depending upon your point of view) is finally getting attention. I still can't promise it will be fixed because unforseen difficulties can put the kabosh on any new development, but I'm putting all the pressure I can to get this fixed.

Want to ask if it's solved in LV 2009 ?

Thanks, eg

[jgcode]

Want to ask if it's solved in LV 2009 ?

Thanks, eg

Hi Eugen

You will be pleased to know, as I am, that is has been

Check out the release notes or I posted details here

[Eugen Graf]

Hey, super. If it's, I will check it as soon as I can.

Thank you for answer and of course AQ for keeping his promise (if it's).

[Adam Kemp]

This is indeed fixed in 2009. VIs in a built executable or DLL are now stored with the same directory structure as they have in the development environment. This also makes code to handle path differences for call by reference in built apps unnecessary, and there's a new VI (Application Path) that returns the directory containing the executable so that you can find files outside of it. Overall I think handling of paths in executables is much easier in LabVIEW now.

[jgcode]

This is indeed fixed in 2009. VIs in a built executable or DLL are now stored with the same directory structure as they have in the development environment. This also makes code to handle path differences for call by reference in built apps unnecessary, and there's a new VI (Application Path) that returns the directory containing the executable so that you can find files outside of it. Overall I think handling of paths in executables is much easier in LabVIEW now.

Hi Adam

I was under the impression that just the files that have name collisions are remapped to folders inside the exe. But from your post and rereading the help documentation, it seems the entire exe structure is mapped as the development environment folder hierarchy.

Is this correct?

Where do vi.lib, user.lib files outside the (top level) src directory go?

Cheers

Time for some playing!!

[Adam Kemp]

Yes, by default all VIs will go into the .exe using the same relative path between them as you had outside the .exe (you can, of course, tell the build spec to put specific VIs in specific locations using custom destinations). It finds the most common root folder of all the VIs and uses that as the top-level directory inside the .exe. If the VIs span drives on Windows then the top-level directories will be the drive letters.

The one exception is vi.ilb, which gets its own top-level directory. This is to prevent common cases from having really deep hierarchies just for vi.lib VIs. This means if you call a vi.lib VI dynamically then you should write a wrapper VI for it in your .exe which you can then call using a relative path. The idea is to not have any code which has to check whether you're in an .exe or not in order to build different paths. The paths should always be the same.

[Shaun Hayward]

Hi Adam,

Does the same thing hold for user.lib / instr.lib, or if we use these shared libraries without providing custom destination will we end up with a huge hierarchy. e.g:

Will it be:

A:

application.exe/main.vi

application.exe/subfolder/subvi1.vi

application.exe/vi.lib/vilibVI1.vi

application.exe/user.lib/_OpenG/openGVI.vi

application.exe/instr.lib/Instrument Driver1/initialize.vi

or

B:

application.exe/Users/ShaunH/Documents/Projects/MyApp/main.vi

application.exe/Users/ShaunH/Documents/Projects/MyApp/subfolder/subvi1.vi

application.exe/vi.lib/vilibVI1.vi

application.exe/Program Files/National Instruments/LabVIEW 2009/user.lib/_OpenG/opengVI.vi

application.exe/Program Files/National Instruments/LabVIEW 2009/instr.lib/Instrument Driver 1/initialize.vi

(I REALLY hope it's A)

[Adam Kemp]

I had to test it to be sure. The answer is A (it also makes top-level user.lib and instr.lib folders if necessary). This means that if you call any of those VIs dynamically then you should also write wrappers for them in your own code to account for any relative path differences.

[gmart]

I had to test it to be sure. The answer is A (it also makes top-level user.lib and instr.lib folders if necessary). This means that if you call any of those VIs dynamically then you should also write wrappers for them in your own code to account for any relative path differences.

Actually it's A-ish. Files that are under the LabVIEW directory are "bucketed" in a LabVIEW folder. So from the example:

A:

application.exe/main.vi

application.exe/subfolder/subvi1.vi

application.exe/LabVIEW 2009/vi.lib/vilibVI1.vi

application.exe/LabVIEW 2009/user.lib/_OpenG/openGVI.vi

application.exe/LabVIEW 2009/instr.lib/Instrument Driver1/initialize.vi

Adam is correct regarding writing your own wrappers. I believe that is mentioned in the help as well.

[jgcode]

Actually it's A-ish. Files that are under the LabVIEW directory are "bucketed" in a LabVIEW folder. So from the example:

Adam and Gmart

Thanks for clearing that up.

[Shaun Hayward]

Thanks guys! That's very useful to know :-)

Shaun

[Daklu]

Wikified.

(Although I'm sure I violated all sorts of wiki rules.)