Jump to content

Jim Kring

JKI Team
  • Content Count

    1,498
  • Joined

  • Last visited

  • Days Won

    28

Everything posted by Jim Kring

  1. 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
  2. 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
  3. 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.
  4. FYI: the official bug for this is the following: Case 10411 - In some cases package icon does not show up in package info dialog
  5. 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
  6. 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
  7. 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
  8. 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!
  9. 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
  10. Please try deleting this line from your .vipb file: mgi_lib_application_control >=1.0.0.11 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?
  11. Oops, the instructions I gave you (for deleting dependencies) are for VIPM 3.0 -- I'll look into the best way to do this for VIPM 2010. Could you please post a screenshot of the Package Dependencies page of VI Package Builder and also attach a copy of your .vipb file? I'd like to look more closely at the current state of your build specs.
  12. Hey Shawn, Thanks for the detailed bug report. I'll look into trying to reproduce this issue. In the meantime, you might try (first backing up your existing .vipb file and then) editing your .vipb file and deleting the MGI Application Control item from the dependencies. [update: Oops, these instructions are for VIPM 3.0 -- I'll look into the best way to do this for VIPM 2010.] For example, you would delete the corresponding item (entire line in red) inside the item, similar to what's shown in red, below (which uses other package names, not yours specifically): oglib_array >= 2.7 oglib_error >= 2.3 oglib_lvdata >= 2.9 oglib_string >= 2.6 Please let me know how this works. -Jim
  13. I'm glad you found the problem and have a work-around Wow, that's a good question. My gut reaction is to call it a bug, but there could be some underlying constraints (in terms of how the build process works) that would make it a "feature". At a minimum, this feels like a definite usability bug, in that VIPM was doing something other than what you asked it to do and it didn't give you any good indication as to why. I'll look into it some more and get back to you. Thanks for your help in debugging.
  14. I believe it's either one of two problems: 1) There are some VIs or other LabVIEW files that are saved in LV 2009, located in your project folder. 2) There's a VIPM bug that's causing the dialog to show misleading information. Just recently, we fixed an issue related to #2. So, I'll send you (by email) a link to a new test build of VIPM to see if that might be the issue. Thanks, -Jim
  15. Hi Vugie, I'm sorry for the trouble. I'm excited to see that you're building your MemBlock toolkit as a VI Package I'll try my best to help. Can you try temporarily disabling VIPM's connection to LabVIEW 2009? In the VIPM Options dialog, uncheck LabVIEW 2009, which will cause it to disappear from the (drop-down) list of LabVIEW versions available within VIPM. After doing this, does the build succeed? Also, can you please attach any recent VIPM error logs you might have, located here: C:\ProgramData\JKI\VIPM\error Thanks, -Jim
  16. Hey Norm, I just did a test and it seems there are still some issues with the build, related to missing VIs. I get the following error: I'm going to work on a fix to VIPM that will improve the early detection of these linker issues and show the missing VIs (and their callers) in a pre-build warning dialog. Stay tuned... -Jim
  17. Hey Norm, I think I found the issue -- I was able to reproduce it on my system, with your sources (you sent me off-line). Try deleting this missing VI from it's owning library: This should allow the build to proceed (at least further than it did before). Thanks, -Jim
  18. Hey Shawn, Thanks for the heads-up. That's a really odd one. It appears that "Is Name Multiplatform.vi" doesn't exist on disk, or that "Open VI Reference" is not able to open it, correctly. For now, since I don't have 8.2.1f4 handy and it seems that your work-around is acceptable, we'll probably just add this in the "known issues" bucket. Still, I've opened an official bug report on it: Case 10397 - Problem building a package using LabVIEW 8.2.1f4 Thanks, -Jim
  19. I'm happy to hear that you got this working. You really shouldn't need to run as administrator in Windows 7 (but, it's a good work-around) -- there's probably a permissions issue with some of the files VIPM touches. I'll ping the JKI team and see about the official way to resolve this issue.
  20. Update: I've emailed you info, Shawn, on how you can help me test the fix for this issue. If all goes well, we should be able to get this fix into the next maintenance release of VIPM 2010.
  21. Hey Shawn, Actually, I take back what I said -- it seems that it was re-saving the XControl in LabVIEW 2009 that fixed the issue. So, I think there are two options: 1) Wait until this issue is fixed. I can probably get you a new, fixed build of VIPM, for testing purposes, soon. 2) Upgrade your XControl to LabVIEW 2009 (or possibly 8.5 or 8.6, but I don't have those installed right this second -- you can test and see if re-saving in either of these fixes the issue). Thanks, -Jim
  22. Can you try running VIPM as administrator and see if that helps? It looks like you have a file permission issue. Which version of windows are you using? Thanks,
  23. Hey Shawn, I was able to reproduce your issue and have a work-around. Try editing the icon of "MGI String Array Control.xctl" and see if you're then able to open the VI Package Sources in VIPM. [update: It was re-saving in LabVIEW 2009 that fixed the issue.] Note: I traced the error to the VI that tries to decode the XControl's icon data (which is stored in the XML file as zipped binary). I'm not sure of the exact cause yet, but I'll look into it some more. [update: It seems that LabVIEW 8.2 doesn't zip the icon data. I'm going to look into how we can improve the parser.] Thanks, -Jim
  24. Hey there, Captain! I'm sorry you're having issues. Wow! (Looking at your screenshot) That is a lot of libraries Yes, please email us your VI Package Sources (to customer-service@jki.net) and we'll take a look. Also, please let us know which additional drivers/software we need to have installed. Thanks, -Jim
  25. Hey Shawn, I'm sorry that this is causing your problems. Thank you for posting the package sources -- it's really helpful. I'll dig into this and let you know what I find. Thanks! -Jim
×
×
  • Create New...

Important Information

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