Jump to content

Jim Kring

JKI Team
  • Content Count

    1,361
  • Joined

  • Last visited

  • Days Won

    17

Everything posted by Jim Kring

  1. 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
  2. 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.
  3. That's an interesting idea -- what sort of customizations/changes would you make?
  4. 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,
  5. 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
  6. 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
  7. 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
  8. 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,
  9. 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
  10. Hi Bob, Great. It sounds like you've got a solution that works well for your needs Thanks, -Jim
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. > 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
  17. 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
  18. Hi Ton, This is a great example of using EasyXML to do something very useful! Thanks for sharing. -Jim
  19. Hi Chris, Thanks for reporting this. I've fixed the glitch. -Jim
  20. Hi Travis, We are certainly aware that resumed support for VIPM on the Mac is an important issue to you, other JKI customers, and LabVIEW users, in general. We can't promise anything right now, but can assure you that Mac support is on our roadmap and is something that is very important to us. What I can say is that the more VIPM Professional and EasyXML customers who voice a need for resumed Mac support, the sooner it will come -- we're working very hard to appropriately allocate our development resources and deliver on our our promises. Thank you for voicing your support for VIPM on the Mac. If you'd like to help us test VIPM on the mac (once it's ready) please let us know. You can start by signing up for the VIPM 2.0 alpha. Regards, -Jim
  21. Hi Lars, Can you possibly post your VI, so that we can take a look at your specific example and try to see how to fix the issue? If you don't feel comfortable posting it, here in the forums, you can email it to support (at) jameskring (dot) com. Thanks for your patience. We'll work hard to try to get this working for you -Jim
  22. Lars, As Philippe mentioned, it's important to use the Variant to Data function to convert to your expected data type: For examples, you might want to take a look at the EasyXML examples that ship with the product, which are located here: \examples\JKI\EasyXML\ Let us know if you still have issues. -Jim
  23. Hi Lars, You are right. EasyXML doesn't support 2D (multi-dimensional) arrays, at this time. I would recommend writing this data as a 1D array of clusters, as shown below: <CT-Unit> <No>16</No> <Name>GE LightSpeed Pro 16</Name> <Phantom>Head</Phantom> <BQ>Head</BQ> <kV>120</kV> <k>1</k> <Sensitivity></Sensitivity> <CT-Unit> <CT-Unit> <No>17</No> <Name>GE LightSpeed Ultra, 8 slice</Name> <Phantom>Head</Phantom> <BQ>Head</BQ> <kV>120</kV> <k>1</k> <Sensitivity></Sensitivity> <CT-Unit> You should check out the recent EasyXML Tips and Tricks post, Creating ordered elements in XML, for more information on how to do this. The reason EasyXML doesn't support multi-dimensional arrays is that, for the first version of EasyXML, we wanted to limit the number of data types supported to those necessary for generating and parsing any XML data. XML does not have any concept of a multi-dimensional array, so we left this out. You might be interested in reading the following FAQ entry for more information on this decision: Why isn't every LabVIEW data type supported by EasyXML? Please let me know if you need any more pointers on getting your application working with EasyXML. I'm happy to help Thanks, -Jim
  24. Hi Bee, I'm not sure who you tried to contact, but you're talking to the right people, now For installing EasyXML onto LabVIEW 8.5 on the Mac, you should follow the method described, here. I realize that this is not an ideal solution -- we're working on improving it. If this technique doesn't work, please let us know and we'll try to help you out, by some other means. Thanks, -Jim
  25. Hi Ton, Thank you for reporting this. Currently, VIPM only supports LabVIEW 6.0 or greater. You are right about the bug. VIPM should have told you that it cannot be used with older versions of LabVIEW. I've created a tracking number (Case 5342) for this -- it should be resolved in a future version of VIPM. Thanks again, -Jim Kring
×
×
  • Create New...

Important Information

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