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

1 Follower

Recent Profile Visitors

6,013 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 VIP
  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 t
  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. 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 do
  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 su
  11. 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 functio
  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?
  • Create New...

Important Information

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