Copy LV palettes from a computer to another

[LAVA 1.0 Content]

Hi all,

I'm about to get a new PC at work and the first thing I'll do after installing LV will be to copy my LabVIEW.ini from my old computer to the new one.

Now I wish I could do the same with my customized tool and function palette ; is there a simple way to do that or do I have to re-edit it all ?

Thanks in advance

[Neville D]

QUOTE(TiT @ Feb 21 2007, 09:54 AM)

Hi all,

I'm about to get a new PC at work and the first thing I'll do after installing LV will be to copy my LabVIEW.ini from my old computer to the new one.

Now I wish I could do the same with my customized tool and function palette ; is there a simple way to do that or do I have to re-edit it all ?

Thanks in advance

Hi Tit,

just copy your /LabVIEW/menus folder from one install to the other. That should copy all the pallet setups. (Be sure to backup the old copy first, just in case).

Neville.

[Jim Kring]

QUOTE(Neville D @ Feb 21 2007, 11:25 AM)

Hi Tit,

just copy your /LabVIEW/menus folder from one install to the other. That should copy all the pallet setups. (Be sure to backup the old copy first, just in case).

Neville.

No, that won't work. LabVIEW (8.x) keeps your palette edits inside the "My Documents\LabVIEW Data" folder. It's not advisable to copy anything from beneath one LabVIEW folder to another -- it's begging for problems (much like manually editing your Windows registry )

[LAVA 1.0 Content]

CITATION(Jim Kring @ Feb 21 2007, 08:50 PM)

No, that won't work. LabVIEW (8.x) keeps your palette edits inside the "My Documents\LabVIEW Data" folder. It's not advisable to copy anything from beneath one LabVIEW folder to another -- it's begging for problems (much like manually editing your Windows registry )

Hi Jim,

Do you mean I actually have to reconfigure the palettes ?

This would be a very nice new feature for the VIPM, on the old computer, save an archive file that contains the packages, subpalettes desciption and so on and then install labview and VIPM on the brand new computer, load that archive file and VIPM does everything to reconfigure the tool and function palettes. That would be so lovely !!

No doubt it would be a lot of work, but I guess it is technically possible, no ?

[Jim Kring]

QUOTE(TiT @ Feb 21 2007, 01:39 PM)

Hi Jim,

Do you mean I actually have to reconfigure the palettes ?

This would be a very nice new feature for the VIPM, on the old computer, save an archive file that contains the packages, subpalettes desciption and so on and then install labview and VIPM on the brand new computer, load that archive file and VIPM does everything to reconfigure the tool and function palettes. That would be so lovely !!

No doubt it would be a lot of work, but I guess it is technically possible, no ?

You should be able to copy your "My Computer\LabVIEW Data\8.2\Palettes" folder from one computer to another and it will copy all of your palette edits to the new computer. Again, don't mess with anything under the LabVIEW installation folder.

JKI is in the concept phase for tools to manage your LabVIEW preferences and palette edits accross multiple LabVIEW versions, using VIPM. I'm as excited as you are and can't wait

[Michael Aivaliotis]

QUOTE(TiT @ Feb 21 2007, 01:39 PM)

This would be a very nice new feature for the VIPM, on the old computer, save an archive file that contains the packages, subpalettes desciption and so on and then install labview and VIPM on the brand new computer, load that archive file and VIPM does everything to reconfigure the tool and function palettes. That would be so lovely !!

Well, VIPM does some of that to an extent. Once you install all of your packages to the new computer via VIPM, you will also get the palletes setup for that package. This is part of the standard package installation process. Of course it doesn't handle customized palette sets or INI settings... yet.

[LAVA 1.0 Content]

CITATION(Michael_Aivaliotis @ Feb 22 2007, 02:32 AM)

Well, VIPM does some of that to an extent.

It does, but only for OpenG packages, if I have some custom packages added VIPM will not deal with then

I don't exactly know how works the palette description (I guess it is in MNU files) but reading these and a computer should give the complete palette description I guess.

By the way, is there any documentation or tutorial to show how to build and add a custom subpalette so that in can be easily deployed ? I guess we need to create an LLB and the MNU file that goes with..

[Michael Aivaliotis]

QUOTE(TiT @ Feb 21 2007, 11:37 PM)

It does, but only for OpenG packages, if I have some custom packages added VIPM will not deal with then

I'm not exactly sure how the OpenG packages create the palette items. I haven't gotten involved in that aspect of it. Perhaps Jim can shed some light.

However, I know for a fact that VIPM does not do anything special with OpenG packages compared to any other package you may install (besides the internet connection of course). So my point is if you add the menu creation in your package, VIPM will gladly set it up for you . Perhaps that is the real problem that should be addressed.

[JDave]

QUOTE(Michael_Aivaliotis @ Feb 22 2007, 01:04 AM)

However, I know for a fact that VIPM does not do anything special with OpenG packages compared to any other package you may install (besides the internet connection of course). So my point is if you add the menu creation in your package, VIPM will gladly set it up for you . Perhaps that is the real problem that should be addressed.

Package creation is an important concern, if not the problem here. I remember looking at the Package Builder a while ago and it was lacking in documentation and help. With VIPM looking and working so beautifully, hopefully there will be a parallel effort on the utility to create packages that are installed with VIPM (bundled up with VIPM, naturally :thumbup: ). Just don't limit it to the Professional version. :thumbdown:

If all these features that are being tossed around about VIPM are implemented, it will truly be the http://forums.lavag.org/index.php?s=&showtopic=3644&view=findpost&p=14700' target="_blank">next must-have app.

[Jim Kring]

QUOTE(dsaunders @ Feb 22 2007, 08:26 AM)

Package creation is an important concern, if not the problem here. I remember looking at the Package Builder a while ago and it was lacking in documentation and help. With VIPM looking and working so beautifully, hopefully there will be a parallel effort on the utility to create packages that are installed with VIPM (bundled up with VIPM, naturally :thumbup: ). Just don't limit it to the Professional version. :thumbdown:

If all these features that are being tossed around about VIPM are implemented, it will truly be the http://forums.lavag.org/index.php?s=&showtopic=3644&view=findpost&p=14700' target="_blank">next must-have app.

David,

We will continue to do everything in our power to make VIPM a must-have app Rest assured, we are very committed to the Community Edition of our product, as we are very committed to the LabVIEW community, in general. If you're impressed by what the JKI team can do with VIPM in our spare time (we are a consulting company, by the way), can you imagine what we might do, if VIPM were our day job? I can sincerely say that your support of the professional version of VIPM will help support the LabVIEW community in various indirect ways. Want proof? Since the release of VIPM 1.0 in January 2007 (just over two months ago), the rate of OpenG library usage has increased by (20x).

Thanks for your support,

-Jim

[JDave]

QUOTE(Jim Kring @ Feb 22 2007, 09:43 AM)

If you're impressed by what the JKI team can do with VIPM in our spare time (we are a consulting company, by the way), can you imagine what we might do, if VIPM were our day job?

I sometimes forget that Open Source is like that. Makes me appreciate all that work so much more :worship: . In all seriousness I think that the efforts of JKI and OpenG greatly benefit the LabVIEW community and show NI that there are professional LabVIEW programmers who want -- and provide -- professional tools. And those come at a cost. I retract my selfish plea. Creating my own packages has just been something that I tried unsuccessfully to do (though I didn't spend a lot of time on it).

QUOTE(Jim Kring @ Feb 22 2007, 09:43 AM)

Since the release of VIPM 1.0 in January 2007 (just over two months ago), the rate of OpenG library usage has increased by (20x).

That is quite impressive.

[Chris Davis]

I've been using the package creator for a while and haven't had any problems with it. Granted what I'm trying to do is not rocket science. In fact the package format, and the package creation utility and is open as well, if you have the time you can explore and / or expand the functionality. I believe Jim and crew are using it now to unit test all the VI's that go into the OpenG packages, amoung other things. Creating your own packages make the installation and configuration manageable through VIPM. Take another look if you get the time.

[Ton Plomp]

QUOTE(Michael_Aivaliotis @ Feb 22 2007, 10:04 AM)

I'm not exactly sure how the OpenG packages create the palette items. I haven't gotten involved in that aspect of it. Perhaps Jim can shed some light.

However, I know for a fact that VIPM does not do anything special with OpenG packages compared to any other package you may install (besides the internet connection of course). So my point is if you add the menu creation in your package, VIPM will gladly set it up for you . Perhaps that is the real problem that should be addressed.

I looked into this, for using a similar technique for our company.

Here's how it goes (according to me, me and eehhhh me)

1. The dynamic palette package creates a new 'Categorie' in the labview palette menu by adding an OpenG.mnu file to <lv>\menus\categories which links to <userlib>\_dynamicpalette_dirs\OpenG
   
2. In that folder is a .mnu file for every category, however there is a (duplicate file located) under <userlib>\_dynamicpalette_dirs\%package%, probably for older versions (6.x and 7.x)
   
3. The .mnu files show the VIs under <userlib>\_openG.lib\%package%\
   

The placement of the *.mnu files is controlled by the package itself!

So the dynamica palette package creates a pipe to a folder with the actual .mnu files

Ton

[Jim Kring]

QUOTE(tcplomp @ Feb 24 2007, 06:07 AM)

I looked into this, for using a similar technique for our company.

Here's how it goes (according to me, me and eehhhh me)

Now you're giving away all my secrets

Yes, that's pretty much how everything works. One key aspect is that the .mnu files for libraries are linked to the VIs in the installed location. And, the installed location is permanent -- we never ever change the installed locations of library VIs. Since the installed location is under user.lib, the .mnu files link to the library VIs using paths relative to user.lib (a feature/quirk of LabVIEW is that files beneath user.lib, vi.lib, instr.lib use paths relative to those folders). So, one benefit of this feature is that the .mnu files can be moved to arbitrary locations and they will always find the library VIs, since the libraries are in a permanent location relative to user.lib. The downside of this feature, is that you cannot move the library VIs to new locations or they will have trouble finding other library VIs. But, it is easy for us to always install them in one and only one location, using VIPM.