Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Mellroth last won the day on May 23 2012

Mellroth had the most liked content!

Community Reputation

0 Neutral
  1. Have you been able to reproduce the bug with the files I uploaded? /J
  2. Hi, Attached is a simple example using the LabVIEW DynamicDispatch example as source. The internal package contains the three classes Shape, Triangle and Square. All these classes have a method named Identify. The public code is supposed to use these three classes internally, but not expose them, hence we add them as an internal dependency. If the wireflow_lib_wf_internalclasses- is added as a internal dependency, the build of the public package fails with the error shown in the attached image, if we remove the package from the list of dependencies the public package package builds just fine. If we monitor the VIPM temp build folder during the build, and if we check other internal packages, we see that the folder where VIPM puts the internal dependencies and adds the name-spacing is a flat structure. Since several methods have the same name it means that they will still have the same name after the name-spacing, resulting in the failed builds /J JKI example.zip
  3. We recently hit a really big bug (at the moment it is a showstopper) when trying to build a new package with a number of internal dependencies. * LV2014 * VIPM 2016 What happened was that VIPM complained about VI salready in memory, throwing error 1357, for several files in the dependency hierarchy. We were able to nail it down to that VIPM puts all dependencies in a flat structure. This means that if you link to a dependency with a class hierarchy and dynamic dispatch, all dispatched VIs will be placed in the same flat structure and thus getting the error 1357. We even tried to workaround this by putting each class in a separate llb when building the vip file of the internal dependency. This probably affects other types of packages, e.g where name-spacing via lvlib is used. I haven't found anything about this being a known issue, so please update VIPM to preserve the hierarchy of the dependencies, or at least handle a scenario with internal deps with name duplicates /J
  4. The same problem appears with additional destinations <Destination_Overrides> <Path>examples\WireFlow_Finger Print Reader.bin3</Path> <Destination>0</Destination> <Additional_Destination>true</Additional_Destination> <Additional_Destination_Index>0</Additional_Destination_Index> </Destination_Overrides> <Destination_Overrides> <Path>examples/WireFlow_Finger Print Reader.bin3</Path> <Destination>0</Destination> <Additional_Destination>true</Additional_Destination> <Additional_Destination_Index>0</Additional_Destination_Index> </Destination_Overrides> In this case it means every package with examples and corresponding exbin files has to be manually updated to support searching in example finder
  5. The list grows... An earlier vipb-file containing name-spacing of a number of lvclasses are now built without namespace added to the files. Looking in the vipb file saved by VIPM 2014 it seems to be a bug with the URI separator, e.g. the following text is from one vipb-files after I showing that if I manually add namespacing again, the item now has two entries with different separators <Namespace_Overrides> <Path>WF-Fingerprint\WF-Fingerprint.lvclass</Path> <Namespace_Type>Suffix</Namespace_Type> <Namespace>_wireflow</Namespace> </Namespace_Overrides> <Namespace_Overrides> <Path>WF-Fingerprint/WF-Fingerprint.lvclass</Path> <Namespace_Type>Suffix</Namespace_Type> <Namespace>_wireflow</Namespace> </Namespace_Overrides> Basically this means that all old vipb configurations is useless until we manually go in and fix the namespacing, or until it is fixed. /J
  6. I’m trying to build a package using some of the newest features in VIPM, licensing and palette binding, and is really frustrated over VIPM. I will try to list some of the most frustrating things here, feel free to separate in different threads, as I don’t have more time to spend on searching for workarounds or understanding bugs in VIPM. 1. Library/class palette errors a.If the source library is pwd protected the palette linking doesn’t work as expected. I guess this is because VIPM cannot correctly set the default mnu in the lvlib. b. If the palette is linked to an lvclass it requires all class members to be not-protected, because all member VIs holds a record of the parent class password . The build succeeds but the palette is not correctly linked to the class c. Both the problems above would be resolved if the building process could ask for passwords on source files. 2. VIPM clears password cache after Pre-build a. To solve the password errors with palettes I tried to use the pre-build VI to add the source code passwords to the password cache. Testing this externally works just fine, but VIPM seems to clear the password cache or is not running the actual build in the same context as the Pre-build VI. 3. Post-build action is not always executed. a. Trying to work-around (again) the palette linking issue by adding a postbuild step that correctly sets the default palette using correct source passwords etc. fails because the post-build VI is not always executed! b. I verified this by trying to display a dialog before my post-build actions could run 4. Packages are included in the package even if they are specified as external a. I scan the project for dependencies, and remove the items I like to be internal from the dependency list, but for some reason all linked dependencies are added as internal. b. This is true for new vipb packages as well as converted from older versions. c. After many hours of debugging, I noticed that the same source folder (fresh from svn) generated a VIP-file without internally added dependencies. This feels really bad; the same versions for VIPM and slightly different LabVIEW versions generates different outputs on different computers. (all dependencies have the same version on both systems) 5. Internal dependencies get an additional 32 bytes (!) per level of dependency, i.e. if a linked library has internal dependencies the resulting names are 64 bytes longer. Meaning that it is easy to reach the limit of 256 bytes and get build errors because of too long file paths. 6. To resolve too long build paths I tried to change the temp build folder in the Options dialog to c:\temp. This didn’t affect the build output, even if the option dialog listed the correct temp folder. I had to close the package builder and change the folder in the option dialog in the main window 7. Even after building successfully with the new temp folder, installation might fail because of the combination of forced inclusion and the 32 bytes added to each level. 8. Changing temp folder to a non-existing folder reverts the temp build path to default instead of previous settings without notice. 9. Passwords are stored in clear text in the vipb file, and I would really prefer if there was an option to give the passwords for the source files by dialog (to solve linking issues with locked source files), and the same type of option for build outputs, i.e. let the user set a master password by dialog, and add “Use master pwd” or something similar to the options. For now I have to keep my old laptop hanging around until this forced inclusion is sorted out. Another option is to locate a VIPM 2013 download and downgrade the vipb file and see if that resolves this issue. The last resort is to go back to OpenG package manager for packaging of our tools. /J Original system (working without inclusion) * Windows 7 home premium * LabVIEW 2012 * VIPM 2014 (build 1941) New system * Windows 7 Pro * LabVIEW 2012 SP1 * VIPM 2014 (build 1941)
  7. Yepp, VIPM 2012 (last patch). I was able to fetch an older version from subversion so we are back on track at the moment. /J
  8. I tried to add Pre-Build and Post-Build action VIs to a package (using Generate VI), and then realized that these actions was only supported in the Pro version of VIPM. VIPM don't complain when building the package, its just that the actions are never invoked. That sort of OK, so I just deleted the Pre- and Post action VIs, but now VIPM complains that the files are missing. Now to the big problem; I cannot remove the links to the files in the build specification. If I try to clear the path, VIPM shows an dialog asking me to upgrade to Pro. To sumarize; if I use the Community edition I can add Build actions that are never used, but I cannot remove them? /J
  9. I have tried on VIPM 2011 and 2012, both with the same result. The attached zip file contains a simple VI and Ctrl together with a vipb file that builds a package that displays the problem. I have checked the dir.mnu file VIPM generates, and it only contains either Control or Function palette data. My guess is that VIPM generates one dir.mnu file for controls and one for functions,. This is OK as long as the controls and functions palettes are located at different paths, but when they are at the same path (in my case the Addons directory) I guess the last generated dir.mnu file is used instead of writing both function and control data into the same mnu file. I tested to write both Control and function palette data to the mnu-file, and this makes everything show up OK. /J Edit: I also included a Post-Install-Action-VI that can be used as a workaround. VIPM bug report.zip VIPM-Post-Install Custom Action.vi
  10. I'm trying to build a VIPM package that should be added to Addons under a new category named WireFlow. If I add both a control palette as well as a function palette one of them (it depends on when the vipb file was saved) does not get placed under the WireFlow category. Instead they are placed under palettes named CTLs or VIs, with a default LabVIEW icon. The files, however, seems to get installed in the right place (Addons\WireFlow), but one of the palettes show up wrong. /J
  11. If you want the class constant to appear on the Control palette; just create a custom control only containing the class constant. Remember to update icon to reflect the class constant. /J
  12. This is normally true for folders outside of the .vipb folder, but does not work for dependencies in user.lib etc. And, as far as I can tell the automatically added dependencies are not renamed. What I want to do is to create a simple vip that doesn't install other packages (like the vipc file), but contains all dependencies but renamed to avoid name collisions. The reason behind this is to make sure my Package A that is using Package C in version 1.0.0 is not affected when I install Package B that is using Package C in version 2.0.0, i.e. I want to be able to have the used portions of Package C in different versions loaded at the same time. /J
  13. Hi, as I remember, the older versions of VIPM had an option to store dependencies in the vip-file itself (but differently name-spaced). Is this at all possible with the current version? /J
  14. In LabVIEW 2009 VIPM fails to build a package where a VI calls the "Elapsed time" function found in the Time palette. The same package could be built in LV8.6, but in LV2009 the build fails. My guess is that the file listing in LabVIEW 2009 includes the cryptic path of the instance VI and that VIPM fails to copy this file. Workaround: remove any calls to "Elapsed time" I also believe that the same error occurs if the or "Time Delay" function is used. /J
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.