I think the problem is in the addBytesToPointer loop over the files. But its possible the error is actually with the number of bytes returned by
String::copyToUTF16. The docs say returns the number of bytes copied to the buffer, including the terminating null character. But when adding the filenames together there is no terminating NULL.

Anyway, i’m sure you’ll figure it out! (I’m on the June 30 GIT, but I did a quick check of the commit logs to see if there was anything added)

I don’t understand… I think my code is absolutely fine. It looks like your change will just leave two null characters after every filename, which would mean that only the first one will be used. My code leaves a single null after each filename, and then two at the end, which is what it’s supposed to do. (Or am I totally misunderstanding?)

Hi Jules,
I assume the copyToUTF16 fix is in the tip, but what do you think about moving this fix also into the juce_153 branch? Bugs like this always seem to pop-up once in a while, one more serious than others. Because you are always working on newer code in the trunk it’s not always safe for us to update to the tip, i’ve done this a couple of times and a few times it fixed a current bug but introduced new ones.
Wouldn’t be a good thing to have a stable branch (1_53) which doesn’t get updated with new features but do get the bug fixes? I know it’s more work but would make more sense. Your codebase is getting so big and with additions like ios and android support it’s much harder to maintain a bug free main branch.

I’ve not put it into the tip yet, because I’m in the middle of the “Jucequake” re-organisation at the moment. When that’s done I’ll probably do a new release soon afterwards, and then might indeed think about stable branches, etc., which will be more straightforward when everything is more modularised.