Palette - Remove .vi suffix by default

[matt.baker]

It would be handy of the palette editor removed the file extension automatically on the short name when added.

[AristosQueue (NI)]

The existence of a .vi extension is important. It is a signal that no title has been set, which impacts localization of a toolkit. I realize that there are other ways to detect when this important step in releasing a toolkit has not been done, but this is the final visual check.

What would be the advantage of striping the .vi extension?

[matt.baker]

Thanks for the explaination of its use - I was unaware of that.

It just looks tidier in my opinion and saves having to remove them manually. For the above example, the reduction of 3 characters allowed the names to be visible in their entirety without the ellipsis.

On another point, It would also be great if more than one item could be added at once, similar functionality to adding multiple items to a project in one hit and automatically avoiding duplicates (for that particular palette).

[crossrulz]

I recommend you have a look at building your reuse libraries into a VI Package using VI Package Manger (VIPM) through JKI.  They have a much better palette editor and it makes it really easy to add your libraries to each LabVIEW install you have.

[AristosQueue (NI)]

I can see Matt's point though for things that are auto-added through stuff like user.lib or just a user who wants to promote his own re-use VIs up in the palettes.

After thinking about it, I think we'll leave the idea open and see what others think.

[matt.baker]

Thanks for the suggestion, crossrulz. The reusable libraries are for internal use only with the main copy held on a server.

I may look into the package manager, but I consider the palette editing a core LabVIEW feature so I would expect this to work well out of the box without the need for an add on.

This raises another question (off topic): if another company has designed a good working add on to improve a core LabVIEW feature and lots of users purchase this addon, would NI feel discouraged to roll out/improve their own version built directly into LabVIEW?

[crossrulz]

Actually, NI ships VIPM with LabVIEW.  And you can do quite a bit with the free "community" version of VIPM, including building packages.  And installing a package is a lot simpler than editing the palettes for every install of the reuse library.

[AristosQueue (NI)]

> would NI feel discouraged to roll out/improve their own version built directly into LabVIEW?

Sometimes yes, sometimes no. And it isn't a simple yes/no question, really... buying the third-party tool to move it in house is also an option to consider. A complete answer depends upon the quality of the third party tool, our evaluation of whether that third party is stable or not, whether we could do better because we have deeper reach into LV's compiler/editor, the relation of that space to NI's core test/measurement/industrial control business, etc. It's really impossible to say in general.

[matt.baker]

Thanks AQ. Good answer. I'm glad to hear all options are open to NI.

[Hooovahh]

So I just wanted to add that we use VIPM for internal reuse, and we also use VIPM's built in feature to add _CompanyName.vi to the end of every file to help reduce cross linking issues to the source, since the files in user.lib will now be different from the source.  I didn't want items on my palette showing up as "Cool Function_CompanyName.vi" so I added a pre build VI (pro version) which would be ran and would set the VI title to "Cool Function" instead and save it.  This way the VI name is one thing, but the VI title (and how it appears on the palette) is set programmatically.  This can also be done just as a normal scripting VI that is ran manually before a build and you can still use the community edition.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.