Modifying NI toolkit

[GregSands]

Is there a recommended practice for making modifications to core or add-on LabVIEW VIs (in vi.lib)?

In my case, I want to develop and extend the functionality of the Wavelet Analysis toolkit, which could involve the following types of changes:

• restructuring to utilize multiple cores
  
• adding new threshold conditions for denoising
  
• developing 3-D wavelet routines (predominantly again for denoising)
  

It will probably only affect a subset of VIs (denoising), but I need the changes to be available on multiple computers. There seem to be a few options:

1. modify in-place in vi.lib and manually copy to other computers
   
2. copy all of the VIs to user.lib and put under SCC
   
3. only put new or changed files in user.lib under SCC
   

Does anyone have recommendations? My thinking at the moment is to make a complete copy to user.lib, and re-parent all the VIs using one or more .lvlib files. This enforces complete separation, and I probably have the most freedom to make the changes I want. But I'd like to hear any downsides to this.

Thanks ~ Greg

[Ton Plomp]

QUOTE (GregSands @ Jun 13 2008, 05:57 AM)

1. modify in-place in vi.lib and manually copy to other computers
   
2. copy all of the VIs to user.lib and put under SCC
   
3. only put new or changed files in user.lib under SCC

1: Never, ever do such a thing. If you as much as repair LabVIEW you will lose your changes.

2: The safest solution, but if NI finds a bug in one of the VIs it is very hard for you to trace.

3: That would be my option

I would keep as much VIs in the same place. So only move the VIs (and it's parents) to a development place.

User.lib is not a place where you keep VIs in development.

Give the description of each VI a common tag like <ChangeForEnhancement> followed by the name and location of the original VI.

Personally I have my tools under SCC in a different location, I built a toolkit of it and that toolkit gets copied to user.lib

Ton

[Justin Goeres]

The best solution, if it's at all possible, would be to wrap the vi.lib members, unchanged, in VIs of your own creation that provide the extended features you need. Even if that results in complicated or slow code, it's the most future-proof way to go about it.

If you can't do the above, then the next best option, as tcplomp suggested, is #3. You should also make sure to use new names for any files you change so that other applications that call those files won't get cross-linked when you open them later.

Generally, it's a really, really bad idea to modify anything in vi.lib, unless NI specifically tells you to or unless you know exactly what you're doing. In either case, whatever changes you make are extremely likely to be overwritten with the next LabVIEW update, which will magically introduce bugs into previously-working code. Insert parable about Man Who Builds House On Sand here .

[GregSands]

Thank you for that - that helps clarify it a lot. I think I was getting a little confused because I probably need to rewrite the code completely, but it's obvious now to make a clear separation rather than imagine it as a replacement or enhancement.

Thanks again.

Greg