Jump to content

Jim Kring

JKI Team
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jim Kring

  1. 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
  2. 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
  3. 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.
  4. 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...
  5. 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
  6. 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
  7. 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
  8. 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...
  9. Hi Daklu, This is an interesting idea. Would such a tool need to be able to uninstall/upgrade packages on the target system?
  10. 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!
  11. 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à
  12. Hey Jon, I'm going to vote that this is a "feature" -- we're phasing out the concept of package revision. Thanks, -Jim
  13. 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?
  14. Just to close the loop on this, publicly... This issue has been confirmed fixed for the next maintenance release of VIPM.
  15. Hi Bob, Thanks for the detailed bug report and steps to reproduce -- it's such a help Now, I think we may have already fixed this issue for an upcoming maintenance release of VIPM. I'll send you some info, off-line, so that you can try testing it out. Thanks, -Jim
  16. Let's just file it as a bug Case 10494: Can't add LLB to Palette as Folder of VIs It should be fixed in the next release. Cheers, -Jim
  17. Great idea! This would certainly be a cool feature. In the meantime, you could store your icon with layers in the icon of a VI that you keep in your VI Package's source folder (for example, rather than creating a Photoshop or GIMP file with layers). You'd then need to copy and paste it from your VI into the (LabVIEW) icon editor in VIPM.
  18. FYI: the official bug for this is the following: Case 10411 - In some cases package icon does not show up in package info dialog
  19. Hey Jon, I can reproduce this issue. In fact, we've already been working on a fix (ping me and I'll fill you in on how you can help test it out) The root cause is that some packages built in VIPM 2010 seem to not have the following in their spec file. [Description] Icon = "icon.bmp" The "fix" is that VIPM now gracefully handles this missing icon info in the spec file. That said, your troubleshooting results (where you're able to fix the problem by adding a border and such) warrant some further investigation on our side, do dig down into the root cause of why the info is missing from the spec file. Thanks, -Jim
  20. Hi, We've confirmed this and have opened an official bug for this: Case 10438: Warnings passed to "error in" are not propagated to "error out" The issue will be fixed in an future release. Thanks, -Jim
  21. Thank you for posting this -- I see what you're saying. I'll pass this along to the JKI team for discussion and get back to you. Thanks, -Jim
  22. Shawn: Thanks for emailing me your sources. I've reproduced and hopefully fixed the issue. I'll follow up with you so that we can test this further on your system. Thanks!
  23. There are a few ways to do this: You can copy all the *.ogp and *.vip package files from the "C:\ProgramData\JKI\VIPM\cache" directory on your networked computer, to your non-networked computer. Also, when you purchased the JKI TortoiseSVN Tool, you downloaded the package file. You can take a copy of this package onto the non-networked computer and double-click it to install. Another way is to use VIPM Professional to create a VI Package Configuration (*.vipc) file and add the JKI TortoiseSVN Tool package to the VI Package Configuration, which you can transfer to the non-networked computer and Apply it. I hope this helps. Thanks, -Jim
  24. Please try deleting this line from your .vipb file: mgi_lib_application_control >= Also, I tried opening your .vipb file in VIPM and I was able to successfully delete all the dependencies -- I can't figure out what's up. Do you have a .vipc file (package configuration) located next to the .vipb file?
  • Create New...

Important Information

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