Jump to content

Jim Kring

JKI Team
  • Content Count

    1,364
  • Joined

  • Last visited

  • Days Won

    17

Everything posted by Jim Kring

  1. > I'm afraid that working in a large international organisation kinda prohibits the arbitrary update to LabView 8.2, regardless of how many nice features are included. It's a shame you impose this constraint, as this seems like an excellent solution for us. But alas... Hi! Yes, I'm sorry that we can't help you out on your older version of LabVIEW. It's a tough decision about which versions of LabVIEW to support, and we have our own constraints that we're working with that impose some limitations on our choices. > Edit: Sorry, it was Tortoise I was referring to. I arrived in this thread through a search for older LV versions. No problem. I've moved your post into the TortoiseSVN discussion forum. Thanks, -Jim
  2. Hi, You can use the XML Load Document function to validate the XML against a DTD (document type definition) file. I think that you need to put the reference to this DTD in the XML file. Also, EasyXML will output an error if the incoming XML file can't be parsed. So, maybe you just need to use EasyXML. Have you tried this yet? Thanks, -Jim
  3. I'm glad it's working now. The error message in your log is one we've seen before and it most likely not at all related to the "missing packages" issue. It's possible that the long delay was because of the upgrade process where VIPM updates its package database files to a newer binary format. Again, I'm glad it's working for you now, and sorry for the trouble.
  4. Do you have a valid LabVIEW version and "All" selected for your quick filter (in VIPM's toolbar)? If you don't have these set right, your package list will get filtered out and not show any packages. -Jim
  5. Hello Heiko, We've seen and fixed this issue. We'll ping you off-line and let you help test a fixed version if VIPM. Thanks, -Jim
  6. Hi Jon, This is by design. You can still add the double underscore to the front of the suffix, but VIPM no longer forces you to use that convention. -Jim
  7. Hi Jason, Thanks for posting your test results. Since PPLs are platform and LabVIEW version specific and they don't support external dependencies, we haven't seem many people (outside NI) using them. We'll spend a little time looking into whether we can reproduce your issue and/or get packaging of PPLs working. Thanks, -Jim
  8. You're welcome and thanks for the extra info. We need to redirect that area of our "old" website to some newer content. So, it's good that you brought it to our attention. Thanks,
  9. Hi Chris, The Configuring VIPM for Package Building instructions don't apply to VIPM 2010. In VIPM 2010, you should be able to build packages, out of the box. BTW, how did you land on that page? I suspect you followed a link from somewhere and I want to make sure that we update those links with current/accurate information. [update: I've added a note at the top of that page telling users that the information is not relevant in VIPM 2010.] Thanks, -Jim
  10. What's LabVIEW 2011? You must be living in the future, Bob
  11. Hey Bob, We've had a few reports of slowness of the Mass Compile step. A couple things to note: - You can press the Abort button on the VIPM toolbar (big red "X" button) to stop the mass compile. This won't negatively affect the installation. - You can disable the Mass Compile after package installation in the VIPM Options dialog. -Jim
  12. We did a reorganization of the forums and those posts got flattened into the main VIPM forum. The posts can still be accessed, they just aren't categorized, nicely in one subforum. Here are a couple: Alternating Row Colors in Multicolumn Listbox Creating System Dialog Buttons with Custom Icons and Mouse Hover Effects
  13. Update: I was able to build a working version of your package (no "dings" ) by opening your project, doing a Save All, and then building the package.
  14. The issue is that these CTL files are broken (Note: I'd classify the "ding" as a bug, personally, since there's no good reason not to be able to drop these onto a Front Panel or Block Diagram, even if they are broken). I'm not sure why this is broken -- it doesn't seem to be broken in your sources...
  15. Hey Fab, Great feedback. We have an open feature request that should address this: Case 8208: "Easy Write XML File" should have a "Overwrite (False)" input. We hope to have this (or something like it) in a future release. Thanks, -Jim
  16. Hi Meg, Sorry for the delay in response. I can see how you'd like to support as wide a userbase as possible. I can't think of a great/easy solution for managing VIs saved in LabVIEW 7. IMO, VIPM provides a lot of nice packaging building and installation features, which do benefit users and provide a compelling reason for them to upgrade to LabVIEW 8.2 (or newer). Thanks, -Jim
  17. Hi Danielle, You should make a separate TestCase class for every different set of setUp and tearDown methods you'll need and make your tests members of the TestCase class whose setUp and tearDown methods they need. In general, there are a lot of strategies and patterns for organizing tests. For example: it is very common to create one TestCase class per feature of your software under test and to create one TestCase class for every class in your software under test. Bottom line, don't be afraid to create more than one TestCase In fact, you could have one TestCase for every single test, but you'll often find that you'll want to reuse your setUp and tearDown methods, which is the reason to start grouping several test methods into the same TestCase. Thanks, -Jim
  18. Jon, This sounds really cool! I'd love to see this in action with VIPM 2010. The one issue I see is that VIPM 2010 is that your script would be modifying the sources of your VI Package, prior to the build. This could create a sticky situation... Are you going to create a post-build script that reverts the changes to the sources? If you revert the changes, what happens if you have uncommitted changes already in the sources? Would your pre-build script require that there be no uncommitted changes in the sources? Another option is to do the entire build process on a copy of the sources. That gets tricky too...
  19. Hi Daklu, This is an interesting idea. Would such a tool need to be able to uninstall/upgrade packages on the target system?
  20. I can reproduce this behavior if I try to double-click either a VIPC or VIP file that's on a network drive that uses UCN paths. I've filed an official bug report: Case 10539: Can't open VIP or VIPC files by double-clicking them if their on a network drive (UNC path issue) I'm pretty sure that this is a bug in VIPM -- I'll we'll deeper into this and let you know what we find. Thanks so much for reporting this issue!
  21. Work-around... Create a VI Package Configuration and add one or more packages. Save it to disk. Remove all the packages. Save it again. voilà
  22. Hey Jon, I'm going to vote that this is a "feature" -- we're phasing out the concept of package revision. Thanks, -Jim
  23. Hey Jon, I recall that we gave these subtleties a lot of consideration when we were in the design and alpha phase of VIPM 2010. In fact, the behavior that you don't want (placing the folder, rather than it's contents in the destination location) is exactly what some other users *do* want. Moving forward, I think that we might need to add one of the following features: 1) Allows you to rename items (or maybe just folders) on install (which is, I think, a feature of the LabVIEW Application Builder). For example: You would specify that your "\examples" folder should be in the "Examples" destination, which targets the "\examples\OpenG" folder. And, you would specify to rename the "\examples" folder as "picture". This would cause it to be installed into the "\examples\OpenG\picture" folder. Or, another option... 2) Have a setting (only available for folders) in the Source File Settings window that allows you to "place contents in destination" rather than placing the folder in the destination. So, if you have the "\examples" folder targeting "\examples\OpenG\picture" it won't end up like "\examples\OpenG\picture\examples\*.*" -- it will just end up as "\examples\OpenG\picture\*.*" (with the "examples" subfolder not added). Thoughts?
×
×
  • Create New...

Important Information

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