[MU4] Fix #319079: Shift Selecting Last Word

[ht-gong]

Resolves: https://musescore.org/en/node/319079

Original code only attempts to find the next ChordRest segment as the end marker for selecting a range, this fix adds the detection for the EndBarLine segment as a potential end marker, which resolves the issue.

• I signed CLA
• I made sure the code in the PR follows the coding rules
• I made sure the code compiles on my machine
• I made sure there are no unnecessary changes in the code
• I made sure the title of the PR reflects the core meaning of the issue you are solving
• I made sure the commit message(s) contain a description and answer the question "Why do those changes fix that particular issue?" or "Why are those changes really necessary as improvements?"
• I made sure the commit message title starts with "fix #424242:" if there is a related issue
• I created the test (mtest, vtest, script test) to verify the changes I made

[Jojo-Schmitz]

Now just the commit message (the body) doesn't fit anymore.

Unfortunatly this change leads to a crash, if the start and end syllable are in different staves (and the end one is at the end of the score and in a higher staff), it dies of a failed assertion:

MuseScore/src/libmscore/select.cpp

Line 709 in 19a0584

Q_ASSERT(staffEnd > staffStart && staffStart >= 0 && staffEnd >= 0 && staffEnd <= _score->nstaves());

Independant of whether we'd use the 1st or the 2nd proposed fix, or none at all.
Without it that selecting in the 'wrong' order doesn't work at all (not even if not including the last sylllable of a score), so this fix just uncovered another bug (but crashes on a debug build only).
Maybe we should remove or modify that assert?
I see nothing strictly illegal about staffEnd > staffStart not being the case.
But while removing that condition from the Q_ASSERT() fixes the crash, it still doesn't make such a selection work :-(

Anyway, this hasn't got anything to do with the issue this PR is fixing.

[ht-gong]

Now just the commit message (the body) doesn't fit anymore.

Unfortunatly this change leads to a crash, if the start and end syllable are in different staves (and the end one is at the end of the score and in a higher staff), it dies of a failed assertion:

MuseScore/src/libmscore/select.cpp

Line 709 in 19a0584

Q_ASSERT(staffEnd > staffStart && staffStart >= 0 && staffEnd >= 0 && staffEnd <= _score->nstaves());

Independant of whether we'd use the 1st or the 2nd proposed fix, or none at all.
Without it that selecting in the 'wrong' order doesn't work at all (not even if not including the last sylllable of a score), so this fix just uncovered another bug (but crashes on a debug build only).
Maybe we should remove or modify that assert?
I see nothing strictly illegal about staffEnd > staffStart not being the case.
But while removing that condition from the Q_ASSERT() fixes the crash, it still doesn't make such a selection work :-(

Anyway, this hasn't got anything to do with the issue this PR is fixing.

Anything that I should do to correct the commit message? The updated commit message is only associated with my second commit.

Also did some tests around the issue mentioned above. Took a crack at a fix by adding this comparison in the Score::selectRange(Element* e, int staffIdx) function that reverses the two indexes if they don't satisfy idx2 > idx1:

            int idx1 = selectedElement->staffIdx();
            int idx2 = e->staffIdx();
            if (idx2 < idx1) {
                int temp = idx1;
                idx1 = idx2;
                idx2 = temp;
            }

Surprisingly, with some elementary testing, this seems to resolve the issue.

[Jojo-Schmitz]

Your commit message is fine, but you should squash those 2 commits into just one (and keep the 2nd message).
Fixing that other issue might be something for a separate commit or even separate PR?
But yes, that additional fix indeed seems to work fine.

[ht-gong]

Oops, wrong button.

[ht-gong]

Your commit message is fine, but you should squash those 2 commits into just one (and keep the 2nd message).
Fixing that other issue might be something for a separate commit or even separate PR?
But yes, that additional fix indeed seems to work fine.

Committing the second fix now :D

[shoogle]

Works for me!