[Reg. 3.3.2 -> 3.3.3] Bar line edit mode is drawn incorrectly after dragging a handle

• Dec 6, 2019 - 10:20
Reported version
3.3
Priority
P2 - Medium
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore

1) Open/create a score with more than one staff.
2) Double-click a bar line.
3) Drag its handle to extend/shorten a bar line.
Result: the edited barline and its drag handle are drawn incorrectly:

Screenshot_20191206_110714.png

Screenshot_20191206_110738.png

In my tests this issue doesn't happen in 3.3.2 version but is reproducible since 3.3.3 version.

Comments

• Dec 6, 2019 - 10:52

I see this in 3.3.4 too, but it fixes itself when leaving edit mode and does not happen if you drag that handle only up to slightly under the upper staff (i.e. not into it)

Reply

• Dec 9, 2019 - 06:10

As I suspected, this issue was introduced with https://github.com/musescore/MuseScore/pull/5156.
That is to say, the fix for #289254: Beams in edit mode: issues with the adjustment of handles.
Or perhaps I should say reintroduced, since it seems it should have been an issue before https://github.com/musescore/MuseScore/pull/4029 was merged.
Apparently there are some cases where we want to call ScoreView::startEdit() upon ending a drag operation, and some cases where we do not.
Perhaps the elements that require that this function be called should include

      ed.view->startEdit();

at the end of their endEditDrag() function.
Adding this line at the end of BarLine::endEditDrag() indeed fixes this issue.

Reply

• Dec 17, 2019 - 10:08
Status active ⇒ fixed

Fixed in branch master, commit 1bdeea30c1

_fix #298196: fix incorrect barline drawing after edit drag ends

Move updateGrips() and other view state-related calls after an
score()->endCmd() call so grips are always updated with actual
layout state.

Also reset BarLineEditData parameters in BarLine::endEditDrag()_

Reply

Fix version
3.4.0