LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How do I control the location of palette files ?

I'm working with a large(ish) base of LabVIEW code that is kept outside of the user.lib folder. I'm trying to create palette files and have them live with the code so that the palette files get checked into the revision control system we use. When I use the palette file editor (Tools|Advanced|Edit Palette Sets) and create new .mnu files I specifythat I want them saved in the same directory as the code is in. However, when I save changes, LabVIEW informs me that it is saving the .mnu files into my LabVIEW Data folder in my user profile. This is no good to me as (a) it's not in my revision control system and (b) it's not available to anyone else logged into the Windows XP machine. How do I persuade LabVIEW to do what I told it to and not try to out guess me ? If I simply copy the palette files over to the code base directory from my user profile they all break as the paths in the palette files seem to be relative rather than absolute and so are not robust against moving the palette files.

 

Gavin Burnell

--
Gavin Burnell
Condensed Matter Physics Group, University of Leeds, UK
http://www.stoner.leeds.ac.uk/
0 Kudos
Message 1 of 4
(1,790 Views)

Have you considered having a subfolder in user.lib/instr.lib in your revision control system? That way you would be able to keep your VIs and MNU files together and your collegues etc would be able to access the shared resources on not only that machine, but any machine where you have your reuse library checkout out to. (e.g. we have a user.lib\<company name> folder that is a checkout location to our reuse library)

 

Shaun 

0 Kudos
Message 2 of 4
(1,778 Views)

I agree that you should try your best to include your codebase in user.lib, especially if you're using .mnu files to include them in the palettes.  However, if you do choose to keep your files elsewhere, you can save the .mnu files into the LabVIEW folder by adding the following INI token:

 

InternalPaletteEdit=True

DNatt, NI
0 Kudos
Message 3 of 4
(1,775 Views)

Ah, the ini file token sounds like what I need to do = will try when next have time. Thanks !

 

I got out of the habit of keeping my codebase in user.lib in LabVIEW 5.1 days when it resulted in LabVIEW taking 20 minutes to load whilst it constructed the palette files (so I fiddled the search path to look for my code ok, but LV didn't load the menus at start up). These days, the problem I have with using user.lib is with our local IT support people who complain if I want to be able to write to C:\Program Files\.... on a regular basis).

 

I have to say that I find editing palette files to be one of the most irritating parts of LabVIEW these days - for example, not being able to edit vi and control icons from the palette editor, not being able to Save As... a palette file to move it to a different location, not being able to ask LabVIEW to try and fix a broken link by using the regular linker resolving rules and not being able to synchronise a palette file to a project, library or class to name but a few. To have LabVIEW refuse to save the palette file where I wanted them to go was just the last straw !

 

Gavin

--
Gavin Burnell
Condensed Matter Physics Group, University of Leeds, UK
http://www.stoner.leeds.ac.uk/
Message 4 of 4
(1,757 Views)