Bug: Hit Enter in tempo marking text box and MuseScore crashes

• May 24, 2023 - 05:24

I posted a similar report about rehearsal marks several months ago. Apparently you're supposed to click outside the text box to confirm the changes. Great, that works. But single-line text fields in virtually every program also accept Enter to confirm the changes.....if you do this in MuseScore's tempo marking text boxes or rehearsal marks, it crashes. I'm guessing in other similar text boxes too, but haven't checked.

I mean...it's OK if Enter just does nothing, and you have to click outside, but crashing?? The rehearsal mark text box bug has not been fixed either. I have the latest version as of this posting.

Please take a look! Thanks!


"But single-line text fields in virtually every program also accept Enter to confirm the changes"
Besides the crash:
Tempo marking text boxes are not single-line text fields, so Enter makes a line break as in every common text program.

In reply to by seejayjames

"why would there need to be any more lines?"

Because, for example, you may have something like "Andante scherzando, non tropo vivo, " followed by a metrical indication in brackets and you need to fold it onto two or even three lines to avoid a clash with another following tempo indication 4 bars later

With rehearsal marks, they are useful to indicate things like "end of first subject", "second subject with variation", "recapitulation in tonic", or other similar signposting longer than a simple letter/number. They need be compact so that they can be located precisely but may need folding so they don't hang over into the margins.

I'm not encountering any problem with multi-line tempo or rehearsal markings. Please attach the score you are having trouble with and give precise steps to reproduce the problem so we can attempt to reproduce the issue before you open an issue on GitHub. Also say what OS you are on.

Note that as mentioned, these aren't "single line text fields" - they are places where you can enter arbitrary text or multiple lines, by design.

In reply to by seejayjames

Thanks for the score. None of these crash for me, so the next thing to figure out is what's wrong with your specific installation. Two things to try:

1) Uninstall / reinstall
2) If that doesn't fix it, Help / Revert to factory settings

Another question - what physical keyboard is this? Something built into a laptop, a wired desktop keyboard, wireless, etc? Also, does it have one or two Enter keys (one possible labeled Return), and if two, which one are you using, and does it still crash if you use the other? Is the layout US QWERTY or something else? Anything unusual about your keyboard settings, like maybe you're using a right-to-left language setting?

In reply to by Marc Sabatella

1) Uninstall / reinstall
2) If that doesn't fix it, Help / Revert to factory settings

Did both. No change.

Physical wired desktop keyboard. Both versions of the Enter key (one on numpad) crash. I use DVORAK layout, but Enter is the same. I also switched to QWERTY just to test---no difference.

Are you on Windows 11 too? This is really strange...

In reply to by seejayjames

One other possible variable: do you have a non-standard font chosen for the UI? The stats bar normally displays the text of the element you are editing, and if that font chokes on the character used in the status bar to substitute for carriage return / line feeds in the actual text, that might explain it. Could be interesting also to try disabling the status bar in the View menu.

In reply to by seejayjames

There were maybe half a dozen reports of this, luckily someone figured out this was the trigger. And several others confirmed that turning it off fixed the crash for them.

But there is also at least one report of someone for whom that didn't turn out to be it - he didn't have that setting enabled. I'm guessing it's some other unusual system setting that somehow behaves similarly.

Do you still have an unanswered question? Please log in first to post your question.