Jump to content

XML file failure


Jason D.

Recommended Posts

Hi Jim: 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.

 

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. 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 hope you are enjoying NI Week!

 

Jason

Enum_Conversion.vi

Link to comment
Share on other sites

Hi Jason,

 

Thanks for your patience while we were at (and catching up from) NIWeek :wub:

 

> 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

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

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