Jules,
Is it possible that Strings members from juce_AudioDeviceSelectorComponent class does not handle non ASCII glyphs, I mean UNICODE glyphs. Maybe it could be the origins of the bad behaviour of this Component.

It’s possible that in reading a string from an ASIO device to juce, the charset may be mis-matched. Ideally drivers would use UTF-8 to return their strings, but since Steinberg’s SDKs were never clear about charsets, the drivers could be returning any kind of format. You could try digging into the ASIO code and see what happens in there.

No… You’re way off track, there’ll be no issue with anything outside of the raw ASIO (or DirectSound) driver code, because it’s all just juce strings, which are completely unicode-safe. The only place that could be a problem would be at the point where raw char* data is passed from the driver, and first becomes a String.

You’ve got some memory corruption going on around that string. But just to make things clear, the problem is completely unrelated to any component or graphics code, or even the String class - those things are just where you’re seeing the effects of the memory being damaged. Like I said in my first post, check the place where that string is first copied from the audio driver.

Certainly I do not know if such method expects a plain ASCII String, an extended ASCII set with ISO 8859-1, ISO Also called Latin-1, or an UTF8 format. But g.drawText does not digest well extended set ISO 8859-1.

Dare I suggest that you try to inject an item String in g.drawText with an extended ASCII character.

Sorry to be obstinate with this topic. The String item is not corrupt in the origin. I’ve made the following test:

Can you put this test program into a GitHub repository that anyone can pull and compile? Make sure to include the JUCE sources in the repository along with the project files (especially Visual Studio 2010).