Multiple palette files in a library/class file causes problems

[gb119]

While developing a labview class, I wanted to set the default palette, so I added the relevant dir.mnu file to the class. Unfortunately, the class already had a dir.mnu file in it. On adding the file, I got some error message about a dependency change*(which makes no sesne, how can a palette file have any dependencies !). On saving the class and then attempting to reopen it, LabVIEW claims it is corrupt. Inspecting the xml .lvclass files reveals that when I added the new paletee file, LabVIEW actually just added a second reference to the palette file already in the project, which it then considers to be a problem when it tries loading the class. This is clearly a bug on a number of levels:

1. It should not be possible for the user to induce LabVIEW to create corrupt xml files through such simple attempts to use documented features.
2. The underlying problem is that LabVIEW appears to be using the conventional search/linking rules to load library items irrespective of whether they are a vi (which should ahve a unique name) or other file (which might well be legitimately non-unique).
3. Given the near impossibility of renaming a palette file without breaking palette links this particular bug is extra annoying.

[Andrew McL]

Hi gb119,

Thank you for contacting National Instruments. I have been doing a bit of research on this and had a bit of feedback to give. Ordinarily, one would never want to have 2 files with the same name contained within the same project. The exception to this rule would be classes that provide a method override in GOOP. In such a case, it would be desirable to have 2 VIs with the same name.

This does not however, help in this situation.  Could you possibly attach your code to this post so I could have a look? Also, why are you embedding Menu palettes into Classes? Could you also tell me which version of LabVIEW you happen to be using?

Many thanks,

[gb119]

I'll create a dummy example that illustrates the effect later this evening - I've now stripped out all dir.mnu from my classes and written a litte utility that writes uniques named palette files direct from the project by using the palette api vis. Meanwhile, this is in LabVIEW 8.6.1, but the same happens in LabVIEW 8.5.

The reason for adding palette files to lvlibs and lvclasses is that it allows you to set the correct palette to appear in the context menu when you right-click by a class wire. This is really very useful when you need to insert a new method vi into an exisiting chain of classes.

[gb119]

Sorry for the delay, it took me a little longer to reproduce the problem systematically. Attached are three zip files of the same trivial class. The only difference between them is the contents of the class file itself.

The key point is that I have two folders in my class - Public and Protected (although I haven't actually set the access scope I realise). Each folder has a dir.mnu file in it and there is also a dir.mnu file in the main class folder. The class virtual folder structure maps directly to the on disc version.

In the first zip file the dir.mnu files are not added to the class.

In the second zip dile I added the dir.mnu by right clicking and doing Add file...  This is allowed because each dir.mnu has a distinct path. I then save the class file and close it.

To get the third zip file, I reopen the class file. I  get a single dependency warning about dir.mnu in one of the sub folders. So I think "fine ok, somethign funny about that dir.mnu file" - note if I'm loading a whole heirarchy of classes I may be told LabVIEW is laoding the dir.mnu file from somewhere completely different in my class structure. I then save the class file to give the thrid zip file.

The lvclass file in the third zip file is corrupt because it has multiple entries for the same file, because it didn't handle having more than 2 items conflicting.

The correct behaviour would be not to invoke the conflicting item names for non vi/ctl document types. I could imagine that there would be similar problems if I had a say a whole range of say README.html files strewn over the place.

[Mark_SAI · Accepted solution]

I was able to reproduce the behaviour described.

This was reported to R&D (CAR ID: 181638) for further investigation.

Thanks for the feedback!

[njg]

There appears to be a new variation of this issue in LabVIEW 2009.  Within NI_AALPro.lvlib (menus->Categories) there is a dir.mnu that is conflicting with a dir.mnu in an lvlib in my user.lib folder.

[J-M]

I also have a similar message (LV2009).

J-M

[gb119]

For now, this is going to bite you ewhenever you have files in libraries that have conflicting names - cross library mislinks as well. The only solution is to avoid putting commonly named palette files into your libraries/class/XControls.

Since having a palette file in a library/class is actually very useful, I created a little utility (here on LAVAG) that would scan the library/class file and create palette files for each virual folder and give them names constructed from the library name and virtual folder path so as to avoid having name conflicts. It will also create links in child class palettes to the parent class palette so that you can right click and access all the method vis in the heirarachy.

[J-M]

Thanks Gavin but unfortunatly it is not solve my problem.


I made a little bit of cleanup and I compared the labiew project under 8.6 and 2009.  I think I was wrong: the problem seems to not be related to LV2009.  Just before the LV2009 upgrade, I have created 3 global variables.  A LV8.6 backup, without the global variables, do not shows this message (8.6 and 2009). Another backup (the last with LV8.6) with the global variables shows this message.  I removed the global variables but the problem is still there. I am not convinced at 100% but the problem seems to be this modification.

Jean-Marc

[J-M]

Sorry,

I created Share variables not global variables.

JM