I’m not sure where to check that. But I definitely haven’t done anything like that manually.
Well what happens if you step through toFullTimecode() and into String::formatted? You can step all the way down to see what’s really happening under the hood. That’s how we’d debug the problem, but if you can’t give us an example to reproduce it, you’ll have to do the digging yourself.
Here’s how it looks at String::formated()
Here’s
formattedRaw() at toFullTimecode line 571
Then at line 577 (seconds subdivisions), it looks normal. num is 4 and temp.get() is :125
I’m not exactly sure what to look for while stepping all the way down. I’m on Windows by the way.
I can send you my project files if you’d like. I just don’t know what to look for.
I think it might be HeapBlock<wchar_t> temp (bufferSize); at line 1850 in juce_String.cpp. As this is where those characters get into temp:
On Windows, this is exactly what is happening.
The documentation of String::formatted says:
If you're really determined to use it, at least make sure that you never, ever,
pass any String objects to it as parameters. And bear in mind that internally, depending
on the platform, it may be using wchar_t or char character types, so that even string
literals can't be safely used as parameters if you're writing portable code.
const char* sign is running everything.
This reminds me of this thread: String assertion in android build