Can I Save As a VIPB File in VIPM and Keep the Old Palette if I Change the Source Directory?

[Filipe Altoe]

Hi Guys;

 

Quick question. I have an old VIPB file for a project and would like to use it for another project. My main interest is to recycle the Palette as I customized it to include a bunch of LV primitives on it. I thought it would be just a matter of saving the VIPB file As another name and change the Source Directory in the Build Information Section. The thing is though, once I change the Source Directory on the new VIPB file, VIPM dumps the old palette altogether and creates a brand new one with the directories that are part of this new Source Directory. Is there a way to reuse the palette from one VIPB file on another one?

 

I'm looking for an easy button to avoid having to spend hours basically replicating what another package already has.

Thanks!

 

 

[LogMAN]

There is to my knowledge no way to retain the palettes when changing the source folder. It's the way VIPM has been designed. However there are ways to get what you want:

 

If you always place the VIPB file in the root folder of the sources, all files are linked with relative paths, so you only have to copy the VIPB file to the new root folder and change it where necessary. As the source path is relative the palettes will persist - or rather you don't have to change the source folder in the first place.

 

Another way is to manually edit the VIPB file. It's basically an XML file and quite easy to read. Search for "Library_Source_Folder" and insert the new path. Or if you just want to replicate the palettes copy the entire "Palette_Sets" subtree.

[Filipe Altoe]

Hi LogMAN;

 

Yes; I didn't know the VIPB file was XML. I just assumed it was a binary file. I decided to try to open it in a text editor and from that point I ended up editing what I needed straight from the file. Thanks for taking the time to answer it.

Cheers.

 

Filipe

[Jim Kring]

Thanks, LogMAN, for the helpful info!

 

Filipe, it sounds like editing the XML worked for your needs. I hope it's all going well for your project.

[Filipe Altoe]

Thanks Jim. Yes; editing the XML did work out great. 

[JKSH]

On 1/19/2016 at 5:54 AM, Jim Kring said:

Thanks, LogMAN, for the helpful info!

 

Filipe, it sounds like editing the XML worked for your needs. I hope it's all going well for your project.

Hi Jim,

I just tried editing the XML on a VIPB file, but VIPM 2016 complained, "VI Package Builder was unable to open the build spec due to an error." Even changing a single letter in the product summary/description triggers this.

Has some kind of checksum system been implemented in VIPM 2016? Is there a way to continue making manual edits on VIPB files?

Thanks!

Edited July 14, 2016 by JKSH

[LogMAN]

2 hours ago, JKSH said:

Hi Jim,

I just tried editing the XML on a VIPB file, but VIPM 2016 complained, "VI Package Builder was unable to open the build spec due to an error." Even changing a single letter in the product summary/description triggers this.

Has some kind of checksum system been implemented in VIPM 2016? Is there a way to continue making manual edits on VIPB files?

Thanks!

It has not been mentioned in the release notes, but "things" change all the times

I have yet to install and test the new version (no need, because if it isn't broken don't fix it...), however I would like to suggest a way for you to check it yourself: Keep the original file and change one character in your description in VIPM, then compare the two files. If there is a checksum there will be an obvious change in one line. If that's not the case you might have broken the package by saving the file in the wrong encoding (UTF-16 instead of UTF-8). Maybe try another editor (Notepad++ is what I work with mostly).

[JKSH]

 

6 hours ago, LogMAN said:

I would like to suggest a way for you to check it yourself: Keep the original file and change one character in your description in VIPM, then compare the two files. If there is a checksum there will be an obvious change in one line.

Good idea, thanks.

So I made sure my LabVIEW code remained unchanged, and I altered 1 character in Basic >> Display Information >> Product Description Summary (from 'o' to 'a'), then re-saved. The following items changed in the *.vipb file:

• The "Modified_Date" attribute in the top-level "VI_Package_Builder_Settings" tag
• The "ID" attribute in the top-level "VI_Package_Builder_Settings" tag
• Every single "GUID" value under the "Functions_Palette_Data" tags.

I'm pretty sure these fields existed in the previous version of VIPM too.., but perhaps they've been given a new role. (If so, why???)

 

6 hours ago, LogMAN said:

If that's not the case you might have broken the package by saving the file in the wrong encoding (UTF-16 instead of UTF-8). Maybe try another editor (Notepad++ is what I work with mostly).

I mainly use Notepad++ too

I know it's definitely not a problem of mis-encoding, because:

1. I used a hex editor (HxD) to alter exactly 1 byte in my Product Description Summary text (from 'a'==0x61 to 'o'==0x6F). That triggered the same error message.
2. I then used the hex editor to change that byte back from 'o' to 'a'. That removed the error message.

Perhaps I should uninstall the latest version and go back to the previous...

[LogMAN]

4 hours ago, JKSH said:

• The "Modified_Date" attribute in the top-level "VI_Package_Builder_Settings" tag
• The "ID" attribute in the top-level "VI_Package_Builder_Settings" tag
• Every single "GUID" value under the "Functions_Palette_Data" tags.

I'm pretty sure these fields existed in the previous version of VIPM too..,

They do exist in files created with VIPM 2014 and they work the same (just checked and got the same changes)

5 hours ago, JKSH said:

but perhaps they've been given a new role. (If so, why???)

 "ID" and "GUID" are both GUIDs, so unless they are calculated based on the configuration data (which makes absolutely no sense), they are just unique identifiers (at least in VIPM 2014).
There might be other changes involved, like comparison of the Modified_Date with the actual file date, but there is no chance to know for certain unless JKI tells us. So in my opinion this is a bug (even though we are technically not supposed to change the files manually).

5 hours ago, JKSH said:

Perhaps I should uninstall the latest version and go back to the previous...

Most changes are of cosmetic nature, the others are only relevant to a very small amount of users. So unless there is a great new feature or a fix to a critical bug, there is no reason to upgrade imo.