Althogh the parallel one getXmlFromBinary() works fine because of the writeByte(0) so it knowns where the string ends,
but the stated size of it is wrong ( destData.getData())[1] ) because destData.getSize() is not the amout of data written to the block but rather the pre-allocated size of the block.
I found this because I've added a binary item after the xml.
void AudioProcessor::copyXmlToBinary (const XmlElement& xml, juce::MemoryBlock& destData)
{
{
MemoryOutputStream out (destData, false);
out.writeInt (magicXmlNumber);
out.writeInt (0);
xml.writeToStream (out, String(), true, false);
out.writeByte (0);
}
// go back and write the string length..
static_cast<uint32*> (destData.getData())[1]
= ByteOrder::swapIfBigEndian ((uint32) destData.getSize() - 9);
}
Hope everything is good, and keep on the good work!!
The MemoryOutputStream will ensure that the block is the correct size after the data has been written to it, and there are definitely 9 extra bytes apart from the string itself. I don't understand what you mean about the pre-allocated size..
This is exactly what I thought but when I"ve added another audio block after the XML, when retrieving it, I found that I was too far ahead with the pointer, the culprit was the reported size of the stored xml, I debuged it and found that it was much bigger then by using out.getPosition() before and after the writing of the xml.
The code works because getXmlFromBinary() uses String::fromUTF8() and you put the out.writeByte (0) so it works without the need to know the right size of the xml (which is wrong and comes to play when you add more fields).
You've explained this several times, but I still just don't understand what you mean!
The current code looks perfectly correct to me - I can't see any way that the memory block would be the wrong size. If you choose to mess around with the memory block by adding your own data, then you can't expect getXmlFromBinary() to be able to handle data this it was never designed to deal with?
