Jump to content

Jim Kring

JKI Team
  • Content Count

    1,476
  • Joined

  • Last visited

  • Days Won

    22

Everything posted by Jim Kring

  1. Hi Doug, I think you are stuck in a time warp! No, literally, I think that your computer's system clock time is wrong. Can you please confirm the date/time? If that doesn't work, then the issue might be that your Windows user account doesn't have permission to modify the C:\Windows\jki.conf file. Can you confirm that your user account has write access to this file? Please let me know if either of these solutions work for you. Thanks, -Jim
  2. Ya, it is a bit of a pain to uninstall a package that has dependencies, just to then re-install (repair) it. It takes a moment for VIPM to resolve the dependencies and then you have to unselect the dependencies in the action confirmation dialog.
  3. Thanks for the extra info. We'll discuss this feature with the VIPM team.
  4. Hi Ton, That's a great idea -- we've noticed that we need that feature, too. It's on our roadmap. Thanks, -Jim
  5. That's a great idea -- I've filed it: Case 5877 - When launching VIPM from LabVIEW, VIPM should switch to that version LabVIEW I should make it into a future release.
  6. We are excited to announce the final release of VIPM 2.0. This concludes the release candidate period and includes improvements resulting for your hard work in testing and providing us with feedback -- thank you! Please see the VIPM (2.0) Final Release Notes page for more information about the improvements made in this release. To download and install VIPM 2.0, visit http://jkisoft.com/vipm/.
  7. Hi, Thank you for the kind offer to translate the package building guide. For various reasons, we can't have our documentation published on other websites or forums. Do you see a large demand for these documents in Russian and/or German? If so, we will consider putting translations up on our website that you can link to from other websites and forums. We are very interested to know how we can better serve VIPM users who do not speak English. Your input and help in reaching these VIPM users is greatly appreciated. Thank you, -Jim
  8. Hi Ton, That's a clever idea. It does have several complications which would make it very difficult to achieve. In addition to access to the file system of the remote machine, we need the ability to launch LabVIEW -- this would be very difficult on a remote machine.
  9. That's an interesting idea -- what sort of customizations/changes would you make?
  10. Hi Ton, > Since it's the postpackage VI that shouldn't be a problem (and it isn't, see below). Oops... you're right. The pre-package and post-package VIs aren't included in the package: only the pre-install and post-install VIs are included. > That fixed it, renaming the ico file to bmp it all worked like a charm. That's great news. I'm glad that you were able to get your package working! Thanks,
  11. Hi Ton, Did you create this package with OpenG Package Builder? There are two problems with the package, that I can see: 1) The package does not contain the post build script VI, "PostPackage.vi", that is declared by the package spec. 2) The package icon should be a BMP file (take a look inside any of the OpenG toolkit packages), not an ICO file. Thanks, -Jim
  12. Hi Jason, Thanks for your patience while we were at (and catching up from) NIWeek > I tried to use XML to persist arbitrary data types to disk. However, the EasyXML file VIs convert the random EOL characters found in my flattened strings so the data read from the file is not identical to the data saved. I think this could be classified as a bug. My original enum was slightly larger (only slightly) and caused LabVIEW to crash every time. The attached example merely throws error 74. > The easiest workaround is probably to read and write the files with separate file I/O calls which call out binary mode instead of text mode. I think that a good solution would be to hex (fast) or base-64 (compact) encode your data before writing it to XML file. I would call this a bug, in the sense that EasyXML doesn't provide an easy way to do what you want. However, there is an expectation (currently) that your string contains data that can be written as an XML element. > Have you given any thought to a way to implement XML CDATA? That might be a better way to handle the storage of flattened LabVIEW data. Yes, we're thinking about ways to implement CDATA. One possible implementation would be to allow the user to append "#CDATA" to the data name/label. This would signal EasyXML to wrap the string data in CDATA tags. We're also considering adding support for the following suffixes #hex (hex encode), #base64 (base64 encode), #zip/hex (zip then hex encode), etc., which would cause the data to be treated before converting to XML. > If you have any other good ways of storing arbitrary LabVIEW data without needing to wire in the data type, I would be interested. I'm a little confused. Are you wanting to parse arbitrary XML without needing to wire in the input data type? Or, are you wanting to be able to flatten and parse data types that are not currently supported by EasyXML? Both are things we're thinking about. > I hope you are enjoying NI Week! NIWeek was great. BTW, we've just posted our presentations, here: http://jkisoft.com/niweek/2008/ Thanks, -Jim
  13. Hi, Right now, the graphical installer is the only way to go. Another option would be to copy the files from a MS Windows machine, similar to the method described in the work-around. Thanks, -Jim
  14. Yes, that is correct: currently, Linux and Mac are only supported in VIPM 1.0 (not 1.1 or 2.0). We hope to restore Linux and Mac support in a future version. Until then, you might try the work-around mentioned here. Thanks,
  15. Sorry, for the delay in response. We've been distracted by the launch of the VIPM 2.0 public beta You have discovered a bug that appears, off hand, to only affect the Numeric data type. For example: try changing your "new feature" Numeric to any other (non-Numeric) data type and it should work. We'll make a note of it and add it to the known issues. Also, if you're an EasyXML customer and this is a show-stopper for you, please let us know and we'll try to get you a pre-release of a fixed version. Thanks, -Jim
  16. Hi Bob, Great. It sounds like you've got a solution that works well for your needs Thanks, -Jim
  17. Hi Bob, I'm still out of town, so I can only answer briefly. I'll be able to spend more time on this, tomorrow. First, XML documents must have one and only one root element (according to the XML spec). For example, the following can be a valid XML document: But, this is not a valid XML document, because it has three root elements: Second, I would avoid trying to parse XML yourself. I think that EasyXML can do everything you need to do. If you are trying to extract an XML element as a raw XML string, you can just use a string data type: Parse_Experiment.vi Hopefully this gives you some ideas about how to achieve your goals. Talk to you more, tomorrow. -Jim
  18. Hi Bob, Everyone at JKI will be out of the office until Monday. I'll make sure to respond with my thoughts on this, then Have a great holiday weekend. -Jim
  19. Hi Bob, I'm glad you got this worked out (and thanks, Ton, for the quick answer). Also, it's on our road map to have VIPM automatically recompile and save the VIs when they are installed. This would mean that you'd never see this sort of situation. Thanks, -Jim
  20. You're right that this error message is confusing. We'll try to address that in a future release. I'm glad you got it working
  21. Hi Arne, Yes, this is the expected behavior. The Easy Write XML File function writes the whole XML file. It does not append and it does not overwrite. In a future version we are considering adding an input that will allow you to select whether you want to overwrite existing files, without an error. As a work-around, you might want to call Delete File before you write the file. Sorry for the trouble. Thanks, -Jim
  22. > I've been very busy over the last weeks and although I'm in the alpha program I haven't had time even to install VIPM 2.0 alpha We hope you can find the time to take the alpha software for a test. We always appreciate your feedback. And, think how much time you'll save once you can use VIPM 2.0 for more effective LabVIEW software reuse! > Awesome job JKI ! Thanks! And, thanks for your support. -Jim
  23. Travis, As part of our commitment to eating our own dogfood, one of JKI's developers has decided to make the switch to Mac to give our team an extra incentive to get VIPM up and running again on the Mac. His new 17" MacBook Pro should arrive sometime this week. We can't make guarantees on when the work will be done, but we're committed to working on it. Regards, -Jim
  24. Hi Ton, This is a great example of using EasyXML to do something very useful! Thanks for sharing. -Jim
  25. Hi Chris, Thanks for reporting this. I've fixed the glitch. -Jim
×
×
  • Create New...

Important Information

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