Jump to content


Member Since 16 Jun 2008
Offline Last Active Sep 22 2017 09:44 PM

Topics I've Started

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   8 downloads
Attached File  VIPM 2.png   36.54KB   8 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.

Fails to Find Dependencies in Custom Actions

29 July 2016 - 03:58 PM

So I have a package that has a Post-Install Custom Action VI but the path to it is not under the main source folder.  As a result when I scan for package dependencies, the ones that the Post Install VI rely on are not listed, and when installing the package on a new machine, the install will fail and I believe it is because it is installed before the dependency, since one was not found.