Jump to content


Member Since 16 Jun 2008
Offline Last Active Nov 20 2017 02:04 PM

Topics I've Started

Package Build Fail if VIM Dependency

13 October 2017 - 07:17 PM

So I can successfully build packages with VIMs in them.  But I found that if I need to make a package, that depends on a package, which contains a VIM, the build will fail.


First install the hooovahh_array_vims- package.  Then try to build the File IO package, which at the moment only contains one VI.  If it is like my setup the build will fail with this error.


Attached File  VIPM Build Fail.png   26.53KB   4 downloads


If I remove the VIM dependency by replacing it with the OpenG one the build is successful.

VIM Package Fails Build if Renaming

11 October 2017 - 05:19 PM

So on VIPM 2017.0.0f1 I'm having a build that fails if I have some specific VIM, and the Renaming Convention is set.  If I don't have renaming, or if I don't include this one VIM then things seem to work properly.  Here is the error


Attached File  VIPM Error.png   40.15KB   4 downloads


And attached is the source and build spec.  If the Filter 1D Array-VIM.vim is removed from the source, then the build works (renaming all the other files to have _Hooovahh as a suffix).  Or if the Filter VIM is left but renaming is disabled the build is successful.

VI Calling VIM Fails to Build

06 June 2017 - 09:26 PM

I've been using the new VIMs feature of VIPM 2017 and am having some issues getting it to build successfully.  If I have a VIM on the palette it builds just fine, but if I add a VI that calls that VIM the build fails, even if that VI isn't on the palette.
Attached is a zip with my source.  It fails to build because the normal VI "Is Variant Repository.vi" calls a VIM that is in that package.  If I delete that VI the build works fine.  Is this a known limitation that a package can't be built, if a VI calls a VIM?  Here are the errors seen when the build fails.  Thanks.
Attached File  VIPM 1.png   33.31KB   12 downloads
Attached File  VIPM 2.png   36.54KB   11 downloads

Add Palette to Library or Class Bug

17 April 2017 - 02:21 PM

So I thought I'd try out the Add Palette to Library or Class option when building a package and I found a few limitations, but first let me mention a bug that I think prevents it from working properly.


I tested the feature by building a package and checking the box, then selecting a .lvclass file that is in my source.  I then built the package and installed it.  But when I right clicked on a class constant or a member of the class the root palette didn't show up like I expected.  I opened the installed class and saw what in my case was the "functions_Hooovahh_CAN.mnu" file added to the root of the class.  I also opened the class in a text editor and saw the line:


<Property Name="NI.Lib.DefaultMenu" Type="Str">functions_hooovahh_can.mnu</Property>


The problem I see is that this is a case sensitive operation.  I editing the text in my class file to read:


<Property Name="NI.Lib.DefaultMenu" Type="Str">functions_Hooovahh_CAN.mnu</Property>


Then closed and reopened LabVIEW and my root menu now shows up if I right click a node on the block diagram.  This was built with VIPM 2016 SP1 2016.0.1 build 1991.


In addition to this I think this feature is a bit limiting.  This feature only works if you are building a package with one class or library in it.  My reuse library is build in ways that mirror the NI palettes, and as a result having a palette like "File I/O" means there are several subpalettes each potentially with their own library.  Being limited to only selecting one library for a package means this just doesn't work properly.  What I think would be a neat feature is to look at the members of a class or library, then figure out what is the most root palette created that a member belongs to, and then add that mnu to the library and adding the default menu there.  I think I can do this in a post-install VI but think others might benefit from a simple one click checkbox which would do this for you.  It is also possible that I'm the only one that has more than one library or class in a package.