Jump to content

Conflicts due to lvlibs in LabVIEW projects


Recommended Posts

One thing that I thought lvlibs was supposed to do was to help prevent conflicts within LabVIEW. I'm not sure if this was a problem in LV 8.6 but I'm using LV2009 now and getting a strange problem.

In my project file, I have two different lvlibs that have a 'dir.mnu' file. These lvlibs are from 1) an Agilent driver, 2) Some NI lvlib (NI_AALPro.lvlib).

Anybody else seen issues like this? What's the solution (my current solution is to ignore the warnings)?

Thanks in advance!

Link to comment

One thing that I thought lvlibs was supposed to do was to help prevent conflicts within LabVIEW. I'm not sure if this was a problem in LV 8.6 but I'm using LV2009 now and getting a strange problem.

In my project file, I have two different lvlibs that have a 'dir.mnu' file. These lvlibs are from 1) an Agilent driver, 2) Some NI lvlib (NI_AALPro.lvlib).

Anybody else seen issues like this? What's the solution (my current solution is to ignore the warnings)?

Thanks in advance!

There are known problems with multiple non-vi/ctl files with the same name in LabVIEW libraries and classes that can result in unexpected cross-linkages between lvlibs or worse, corrupt files. See this thread on NI's forums for details.

Essentially it appears that the loader uses the standard LabVIEW linker rules about how to find a file when loading the members of a library. Whilst this is perfectly sensible for LabVIEW VIs, custom controls etc which should have a unique name, it is less than helpful when the library files contain other types of file that may legitimately have the same name - such as dir.mnu files. This isn't a problem in project files as in that case the members aren't all loaded into memory when the project is.

The solution is to move the dir.mnu files out of the lvlibs, or to rename/recreate them with unique names. Your current solution will go very badly wrong if you ever have multiple dir.mnu files in the same lvlib !

Edited by gb119
Link to comment

There are known problems with multiple non-vi/ctl files with the same name in LabVIEW libraries and classes that can result in unexpected cross-linkages between lvlibs or worse, corrupt files. See this thread on NI's forums for details.

Essentially it appears that the loader uses the standard LabVIEW linker rules about how to find a file when loading the members of a library. Whilst this is perfectly sensible for LabVIEW VIs, custom controls etc which should have a unique name, it is less than helpful when the library files contain other types of file that may legitimately have the same name - such as dir.mnu files. This isn't a problem in project files as in that case the members aren't all loaded into memory when the project is.

The solution is to move the dir.mnu files out of the lvlibs, or to rename/recreate them with unique names. Your current solution will go very badly wrong if you ever have multiple dir.mnu files in the same lvlib !

Thanks, I will try your suggestion.

FWIW - I don't have multiple dir.mnu files in the same lvlib, these are in different lvlibs as shown here

post-5746-125261933359_thumb.png

Link to comment

One thing that I thought lvlibs was supposed to do was to help prevent conflicts within LabVIEW. I'm not sure if this was a problem in LV 8.6 but I'm using LV2009 now and getting a strange problem.

In my project file, I have two different lvlibs that have a 'dir.mnu' file. These lvlibs are from 1) an Agilent driver, 2) Some NI lvlib (NI_AALPro.lvlib).

Anybody else seen issues like this? What's the solution (my current solution is to ignore the warnings)?

Thanks in advance!

I have seen the same.

I'm working on some drivers libs. And I have them all in the same project. And I have some challenged concerning the names on the IV. Some is natural to have the same name. Some not. But that LW is reporting that I have 2 files with same name :throwpc:

If anyone have some suggestions I be happy to hear about it

Thanx

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.