Fix GH#16363: Accidentals in chord symbols rendered incorrectly when using custom XML file

[Jojo-Schmitz]

Resolves: #16363

[cbjeukendrup]

If code.startsWith('&') is true, then this would fail anyway. Does this case occur at all?
If not, let's not check for it, because that only makes the code noisy
If yes, we should add proper handling for that case.

However, I'm not very confident whether I like this approach; it means that our String::number method behaves differently from QString::number, which seems a potential source of confusion.
Wouldn't the problem be fixed instantly if you do

Suggested change

	char32_t val = code.toUInt(&ok, 0);
	char32_t val = code.toUInt(&ok, 16);

and drop all other changes? Or is it not certain that it will be a base16 number?

[Jojo-Schmitz]

If code.startsWith('&') is true, then this would fail anyway. Does this case occur at all? If not, let's not check for it, because that only makes the code noisy If yes, we should add proper handling for that case.

We don't have full control over the content of a chords.xml, it could contain ♭ (@MarcSabatella even recommeded the latter in the issue as a workaround, #16363 (comment)).

The toUInt(..., 0) would fail on it (as would a toUInt(..., 16)), but return the string unchanged, as far as I understand.

Be generous in what you accept, but strict in what you generate ;-) (and that's why toUInt(..., 0) exists)

However, I'm not very confident whether I like this approach; it means that our String::number method behaves differently from QString::number, which seems a potential source of confusion. Wouldn't the problem be fixed instantly if you do
...
and drop all other changes? Or is it not certain that it will be a base16 number?

The problem isn't that toUInt()doesn't return a hex number, but that this number as a string doesn't look like one to the writer because of the missing "0x".
Also, as said above, it might be an octal number od a string with an HTML entity, we don't have full control over the content of these files.

But we can leave the String::number() as it was and just do it like in the 1st commit and prepend the "0x" there,
after all we do know though that we write as hex there.

[Jojo-Schmitz]

I can understand your concerns reg. different behavoir of String::number() vs. QString::number(), so reverted that 2nd commit

[Jojo-Schmitz]

And we may not need the read fix at all, as save/close/open fixes the issue too, its just nice to have, isn't it?

[Jojo-Schmitz]

BTW: this would work too:

                        int base = 0; // guess, based on content
                        if (!code.startsWith(u"0") && !(code.startsWith(u"&#") && code.endsWith(u";"))) {
                            // fix broken chord lists, see https://github.com/musescore/MuseScore/issues/16363
                            base = 16; // force hex
                        }
                        bool ok = true;
                        char32_t val = code.toUInt(&ok, base);

And it does read that ♭ too, not a © though, toUInt() (or rather rather std::strtol()) probably just ignores all the non-alpha-numerical chars and (rightfully) interprets the rest as decimal.

[Jojo-Schmitz]

Came up again in https://musescore.org/en/node/364348