Focus lost after change of note duration on 2nd or 4th note of beamed group

• Dec 3, 2014 - 05:52
Type
Functional
Severity
S4 - Minor
Status
closed
Project

Ubuntu 14.04, GIT commit: 408c73d

Usability issue that appeared at some point since Beta:

1) empty score
2) add a single quarter note
3) leave note entry mode
4) click the note
5) press "4" to change to eighth note

Result: focus is lost

In 1.3 and in earlier 2.0 builds, focus would be left on the shortened note, allowing you to then go directly into note entry mode at that position. Now, if you try to go into note entry mode, you end up at the beginning of the score. Of course, this won't happen if #33996: A way to get back to the previous editing position after pressing Escape (without using the mouse) is fixed. Still, we shouldn't lose focus in the first place in this case.


Comments

Title Focus lost after change of note duration Focus lost after change of note duration on 2nd or 4th note of beamed group
Status (old) fixed active

My fix got most cases I think, but it seems there are still missed cases. Either that or something else broke these cases subsequently. Try the following:

1) enter four eighths into an empty bar of 4/4
2) leave note entry mode
3) click the second of the four eighths
4) press 5 to change to quarter

Result: focus lost (note no longer selected)

It seems specific to the second & fourth notes of a beam group - it happens the same way for sixteenths. That's the case in 4/4 time anyhow. In 6/8, the problem affects the second eighth note (which is the second note of the first beam group) and the fourth eighth note (which is the first note of the second beam group).

Nothing broken I think since the last correction.
Indeed, in the newly reported case (with 8th and second & fourth notes, and also with 6/8 measure), I can say that the origin and the behavior are the same between the two Nightlies of November 22 (see comment # 1 ). Correct with the first, wrong with the second.

Status (old) active patch (ready to commit)

https://github.com/musescore/MuseScore/pull/1532

I say "ready to commit", because I am confident enough that my code fixes this particular problem and doesn't introduce any others. But there is one thing I don't understand in that section of code that I tried to explain in the PR comment, that could mean there is still some case where we don't select something we should.

FWIW, same bug affects a note *on* the beat if it is tied into and you lengthen it using "." rather than a number. Luckily, the same fix applies too :-)