Jump to content

Jim Kring

JKI Team
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jim Kring

  1. 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
  2. Hi, This issue should be resolved in VIPM 2010.0.1. Please, see here for more details, and let us know if it fixes your issue. Thanks, -Jim
  3. Hi Jim, I'm really sorry for the long delay in response. You asked a relatively non-trivial question, so it wasn't one that could be answered quickly. Here are my thoughts: Parse State Queue is reentrant, and LabVIEW doesn't provide a super-easy way to get the references to instances (a.k.a "clones") of reentrant VIs. I think what you would need to do is get a VI reference to the VI that contains the JKI State Machine, and then traverse its block diagram for GObjects of type "subVI" (using "vi.lib\Utility\traverseref.llb\Traverse for GObjects.vi" -- see here for tips from Darren). You would can then get the instance/clone VI reference from the subVI reference, check if it's VI.Name is Parse State Queue and then get it's Front Panel control references. Whew... that was a mouthful Let me know if you have any questions about this. I'm happy to help. Thanks,
  4. Hi Markus, Great, I'm glad that worked! Let us know if you have any other issues or questions. Thanks, -Jim
  5. Michael is a VIPM super-star!

  6. Hoping there are no major issues with the JKI forum upgrades :)

  7. Well, since you asked... the issue is that the "Write Linker Info" Application Method (it's a private one) does not like it when you pass in a path to Class Private Data (which appears as a VI/CTL in memory with a virtual Path value like "C:\MyProject\MyClass.lvclass\MyClass.ctl" -- the Class Private Data is not actually a file on disk). So, before we call Write Linker Info, we filter the Class Private Data from the list of paths. However, our Class Private Data detector was not handling the situation where an LVClass was inside an LVLib -- this was making the VI.Name attribute of the Class Private Data look something like "OuterLibrary.lvlib:MyClass.lvclass:MyClass.ctl", when our parser/detector was looking for something like "MyClass.lvclass:MyClass.ctl". When a package is built, the "Write Linker Info" method is only being called when there are additional resource files, like DLLs, present in the VI package (since we move these on disk, rather than using VI Server Save Instrument, like we do for VIs). The end result is that this bug only shows up when a VI Package includes a DLL and an LVLib that contains an LVClass.
  8. Hi Markus, I think your web browser (my guess is that you used IE) added a ".zip" to the end of the "jki_lib_easyxml-2.0-2.ogp" file name. Rename the "jki_lib_easyxml-2.0-2.ogp.zip" as "jki_lib_easyxml-2.0-2.ogp" and then double click on it -- then VIPM will install it as an upgrade to the demo version (VIPM will uninstall the demo and then install the paid version). Please let me know if this works for you or if you need any other help getting this working. Thanks, -Jim
  9. Thanks for the update. Let me know if you have any questions or issues with the variant manipulation. My guess is that I have about as much experience with this as anyone on the planet
  10. We include a list of fixed issues and new features in the release notes of new versions. Also, you can feel free to inquire about the status and we'll let you know. I'm pretty sure (but not 100% positive) that your work-around, using control references, won't work. The VIs will probably still have their front panels, but I think that they won't be loaded into memory and you'll get an error. Yep, that's exactly what I meant: the OpenG LabVIEW Data Tools library (oglib_lvdata package). These are the VIs that we use, under the hood of EasyXML, to manipulate the LabVIEW data as a variant. I noticed Thanks for the feedback. -Jim
  11. Guys, I'm pretty sure I've found and fixed the issue. I've attached a fixed version of ogb.llb that you can put inside the "support" folder of the VIPM installation directory (make a backup of the original first, in case you run into problems and need to revert to the original). Please try this out and let me know if your builds work. ogb.llb.zip It turns out this this is a bug that affects building packages that contain both a DLL and an LVLib that contains an LVClass (talk about a corner case). Cheers, -Jim
  12. I'm very curious to dig into this and see what's the matter. We'll definitely need to reproduce the issue on our system, to see what's wrong. Can you post (or send us off-line) an example of a VI Package project that shows this problem? Thanks, -Jim
  13. Great! I'm happy to hear that VIPM 2010.0.1 solves this problem Thanks for all your help in reporting this issue to us. -Jim
  14. Hi There. Just a quick update. This bug should be fixed in VIPM 2010.0.1 -- you can find more info in the release notes, here: http://jki.net/vipm/release-notes Thanks! -Jim
  15. Hi There. Just a quick update. This bug should be fixed in VIPM 2010.0.1 -- you can find more info in the release notes, here: http://jki.net/vipm/release-notes Thanks! -Jim
  16. Hi Fab, I'm happy to hear that you love EasyXML An option to use the input data type as the default values for the output sounds like a great feature addition, to me. We'll certainly add this to the list of feature ideas for a future release (and, I've heard this suggestion at least once or twice from other people). I've filed an official feature suggestion, in our tracker: Case 10191: Need an option to use the input data type as the default values for "Easy Parse XML" Regarding your solution (it's great, BTW!), I would probably use variant manipulation instead of control references, since control references requires the front panel to be loaded into memory and can cause some complications during the application build process and also can cause some performance issues. However, doing that requires recursion, which is a bit more complicated Cheers! -Jim
  17. Do you have write permission to the folder that contains your VI Package Source Folder? When VIPM builds your package, it creates a copy of your VI Package Source in the same folder as your VI Package Source Folder, but with a dot "." in front of it. If VIPM can't create this folder, then the build will fail.
  18. This really looks like a file permissions error, where VIPM does not have permission to create the temp folder required to do the build. Are you certain that your user account has permission to write to the temp folder? This is really odd -- sorry it's such a tough problem to debug.
  19. Hi there, Thanks for using JKI products I'm happy you like them. Have you tried building your package on other computers and other operating systems like XP or Windows 7? It does seem odd that the temp build folder would disappear before the build is completed!?! Maybe it is related to running VIPM and LabVIEW as different users, but you do say that you tested that... Thanks, -Jim
  20. Hi Henning, If you contact our support department (http://jki.net/contact), we can send you a fixed version. This hasn't been officially released yet. Thanks, -Jim
  21. Thank you for reporting this issue. Yes, it's related to the "instance" VIs in the VI hierarchy due to the Express VIs. It's on our radar and has been fixed for the next release. Thanks, -Jim
  22. Hi Dave, Yes, please upload your code to us -- I've sent you instructions, off-line -- and I'll take a look at the problem. From your description and the error log, I've got some ideas about the nature of the problem. Thanks, -Jim
  23. I agree that this would be extremely useful. We have an internal tracking number for this feature request: Case 9969: VIPB Palette Editor should allow copying palette items via Ctrl+Drag Thanks, -Jim
  24. Hi Jonas, I'm happy to hear that you're liking the package build numbering scheme used by VIPM. We don't have anything, yet, to report on the "release stage" idea. But, we're definitely listening. We do have an internal tracking number for this feature request: Case 9968: Add a "Release Stage" field to VI Package version information Thanks for reminding us and pushing us to work on ideas you need. We really appreciate your feedback. -Jim
  • Create New...

Important Information

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