Small request for XmlElement RE BinaryBuilder data


#1

I was half tempted to expand upon BinaryBuilder, adding some functions to the generated code to make it simpler to read the data in an appropriate format. However, there’s not really any simpler way to read in Image data than with ImageCache::loadFrom() - any function for that would just be identical.

So, any chance of a simple static XmlElement* XmlElement::loadFrom(const char* binaryData, const int size)? It doesn’t really save much work at all, granted, but what it does do is save the hassle of trying to remember the steps involved to read XML from embedded binary data.


#2

Hmm… Well maybe. Not sure why, but it feels like the wrong place for that kind of thing, though.


#3

Actually, i guess it would make enough sense for it to be in XmlDocument (you can go to ImageCache to return an image from binary data, so you could go to XmlDocument to do the same for an xml element).

I know it seems like a very pointless function to request, but every time i want to read stuff embedded with BinaryBuilder, I always have to try and remember the steps to call. It’d be neat if there were such ‘loadFrom’ functions for most common data types.

I might just stick with my original idea anyway though - adding an option for generating some helpers to go inside the binary data source files. Like, readAsImage(), readAsXml(), readAsString(), etc.

Perhaps Juce could be extended slightly to have a ‘BinaryData’ class with such functions (with a const char* and const int), and BinaryBuilder could make instances of that class for each file. That way you could just say MyBinaryData::systemconfig_xml.readAsXml (). You wouldn’t have to faff around with the two parameters, and you wouldn’t have to remember anything.

I’ve been tempted to add a GUI to BinaryBuilder for a while, perhaps when I get some time I’ll just do it up myself :slight_smile:


#4

[quote=“haydxn”]
Perhaps Juce could be extended slightly to have a ‘BinaryData’ class with such functions (with a const char* and const int), and BinaryBuilder could make instances of that class for each file. That way you could just say MyBinaryData::systemconfig_xml.readAsXml (). You wouldn’t have to faff around with the two parameters, and you wouldn’t have to remember anything.

I’ve been tempted to add a GUI to BinaryBuilder for a while, perhaps when I get some time I’ll just do it up myself :)[/quote]

fair point. i’ve experienced the same need when dealing with lots of different embedded file type.

and regarding the latter, probably you can use rejuce (here). it’s a bit old (linked with old version of juce and probably need some refinement) but i use it now already cause it use a jrc xml file for the actual files to generate (so you can regenerate the file easily).


#5

That’s a nice idea about the BinaryData class - I’ve thought about doing something along those lines. It’d also mean you could do things like storing the data in a compressed format, but exposing it as streams that decompress it from memory.


#6

Hey,

I’m basically trying to accomplish the same thing the OP mentioned 10 years( :-O) ago.
I’m trying to read an XML Document from my Binary Data Resources.

Haydxn, you wrote

It doesn’t really save much work at all, granted, but what it does do is save the hassle of trying to remember the steps involved to read XML from embedded binary data.

Could you or anyone elaborate what the steps are to read an XML Document from BinaryData? I have been searching for a while, something like (ImageFileFormat::loadFrom() ) really doesn’t exist for XML, does it? I’ll happily do it manually, but I have no clue on how to put these numbers back together into my original XML Document. Any help would be greatly appreciated.

Thanks, and sorry for reviving this zombie of a thread :slight_smile:


#7
    std::unique_ptr<XmlElement> xml (XmlDocument::parse (BinaryData::myFile_xml));

But please don’t wake these old threads from their slumber! (I thought I’d locked all the really old ones, as it makes it confusing for people if the info in them is out of date)


#8