Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


jgcode last won the day on December 22 2010

jgcode had the most liked content!

Community Reputation

2 Neutral

Recent Profile Visitors

5,709 profile views
  1. Well that is not always the case, for example - if you are building a tool to put on the LVTN and it includes links to your company's reuse library, you are not going to distribute your company's packages, it is more convenient to include those VIs internal to the package. Additionally I prefer creating/distributing tools that have no external dependencies. As mentioned previously I am working outside of VIPM here, this was due to some issues that may have been resolved in an upcoming VIPM release - so I am eager to test it out
  2. Thanks for the reply Michael. Essentially I am working outside of VIPM here (woah! crazy I know ) and it breaks my code - I will try to explain better: Lets say I have A.vi which was was installed via a VIPM package called Package A. A.vi calls the following VIs Aa.vi and Ab[iD String].vi (all internal to the Package A). However Ab[iD String].vi is obviously an internal VIPM dependency of Package A (that originated from another package but was included in Package A for whatever reasons etc...) Now I am working with a new project (.lvproj) in LabVIEW, which has nothing to do with VIPM and my new VI 1.vi calls A.vi. In order to create a source distribution of my new project, I add all the calling VIs to the .lvproj file. As I am going to need to export: 1.vi, A.vi, Aa.vi and Ab[iD String].vi. However (and this is where the problem is occurring) - if I build and install a new version of Package A then it's ID String of it's internal dependencies changes. The next time I load the .lvproj file it cannot find Ab[iD String].vi and the source-dist build cannot run (broken). If the ID String stayed the same, this issue would not occur. Hope that makes things clearer? In terms of the workflow I understand that Ab[iD String].vi (although not scoped) is a private VI that should not be called on any block diagram so it's name is irrelevant. This is still the case here however, it needs to be included in the .lvproj so I can create a source-dist of the code that does not have any dependencies (or rather can have selected dependencies). Regards -Jon
  3. I ran into the following problem the other day. I was building a source distribution with the LabVIEW App Builder (not VIPM) and the .lvproj file included dependent VIs (from VIPM packages, as well as any of their internal dependencies too) in a virtual folder so that they can be included in the source-dist. It happened after I updated a package and installed the latest version. It went something like this: I went to build some code and I got this error: I checked my .lvproj (you can't see but these were in a Virtual Folder under My Computer NOT the Dependencies ProjectItem) and there was missing VIs - weird!: I knew the package was installed so I checked the .lvproj's Dependencies and that's where I found the VIs I was looking for and also discovered the VI names had changed: The dynamically changing names had broken my build! Of course the workaround is that anytime I update this package I have to manually update the .lvproj. Granted this use case might be limited however, my proposal is that the ID string (or whatever it's called) used to rename internal dependencies becomes a property of the .VIPB and is reused on subsequent builds (but if there was a need there should be a way to reset it - I cannot think of one at the moment). This would fix this issue. Thoughts? Regards -JG
  4. I just put different libraries/classes in different .LLBs (or folders) in the same package. No dramas. Is that something you can do?
  5. Thanks Ashish - do you have a workaround to get access to the data? Cheers -JG
  6. Build Hook Parameter - Password

    Hi Anhish No, as per the title of the thread, I am talking about the Password parameter passed in, in the pre or post build hook. I am guessing it is an array of passwords generated/used in the VIPB settings? Cheers -JG
  7. Is there any workaround to get the data into the hook? Cheers -JG
  8. I see that there is a Password parameter (string array?). What is it? And what can it be used for? Cheers! -JG
  9. VIPM 2011.0.1 (build 1692) Steps to reproduce the bug (if it can be reproduced) Create a package in VIPM using LabVIEW 2011 Add a Pre and Post build hook and configure to return information Expected behavior (what would happen if the bug didn't exist) When the package is build, information is available in each script (through variant attributes) Actual, observed behavior (the bug) No information available in either build script as variant input is not updated Test Hook.zip If I run this in LabVIEW 2009 it works fine, but when I run it in LabVIEW 2011 it doesn't work. This is on the same PC (Windows 7 x64) so it must be related to a change in LabVIEW 2011? Attached is the code used in the above report (Build Hooks aren't excluded in build spec but doesn't matter). This issue would not affect un/install scripts as they have no data passed to them. Cheers -JG
  10. Firstly, congrats on the 2011.0.1 release. I have some feedback on Case 12969 which does not allow e.g. a period in the Company Name and overrides it to an underscore. E.g. OpenG.org => OpenG_org In the release notes, it says that this is to prevent VIPM from creating package names with hyphens and periods. However, adding a period to the Package Name is allowed (e.g. this could affect the rebuilding of legacy packages - so that makes sense). In summary, I am suggesting is that the Company Name should allow periods however, it should override the hyphen in the suggested Package Name (if that is where the issue is).
  11. Custom Category Icon

    Hi Chris I suggested this here. Cheers -JG
  12. VIPM 2011.0.0 (build 1669) I came across this when developing for Team LAVA, but you can see it in OpenG. Steps to reproduce the bug (if it can be reproduced) Create a package with a Custom Category. Add a functions and a controls palette. Expected behavior (what would happen if the bug didn't exist) The package creates Custom Top Level Menus for both the Functions and Controls Palettes. Actual, observed behavior (the bug) No Custom Top Level Control Menu is created. Therefore the default is used. Using OpenG as an example which makes use of the Custom Category function you will see that the Functions Palette is fine: However, the Controls Palette is not: The Buttons package (only package that has controls) is installed and the VIPB specifies a Custom Category: You can see the dir.mnu file (which is what the Categories folder calls its top level menu) is missing. Which is also evident in the spec file: A Top Level Palette is still created as the folder "OpenG" exists (no leading underscore) but the name (folder name) and icon use default data. I have a workaround for now which is to make my own palette .ogp package (just like in the old days) and link to that. Cheers -JG
  13. Sorry for the delay in replying, Yes I believe the above is correct for that package. But the Dependency of a package is really for that which is required in the LabVIEW Development Environment. This is a dependency for the Installation/Uninstallation - maybe it could also be handled by declaring dependencies for the scripts?

Important Information

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