Unable to create barline after undo

• Apr 4, 2014 - 17:41
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore
Tags
barline
2.0

WIndows 7, GIT commit: 6c5b016

1) create new piano score, 32 bars
2) drag "start repeat" to first measure of second system (bar 18 on my system)

Result: layout changes, pushing bar 17 down to second system - no reason for this that I can see

3) undo

Result: bar 18 is now the first measure of the system again

4) drag "start repeat" to bar 18 again

Result: layout shifts as before, but no barline appears

If I delete all measures and append new ones, I can no longer reproduce any of this this. If on the other hand I delete all but the first measure and append new ones, I still see the problem. The only obvious difference is that deleting *all* measures then appending new ones leaves me with no time signature - wonder if that's the key somehow?

Comments

• Apr 4, 2014 - 19:44

I ran into this trying to track down a score corruption that results after a series of barline operations. I still don't have a simple reproducible case, but I've been hitting it repeatedly on one given score. I'm pretty sure I never actually hit "undo" in that case, so it may be unrelated, but just a heads up that there are more barline troubles ahead...

Reply

• Apr 4, 2014 - 20:00

Here is the score corruption issue as best as I can get it right now:

#25253: Multimeasure rests corrupts multi staves instruments

At this point, the corruption appears with only a part create, save, & reload - but the last thing I did before getting into this state was play around with the barline at C. It was in trying to reproduce that sequence of events in a simpler score that I discovered the current issue with creating barlines after undo.

Reply

• Apr 9, 2014 - 08:13

I could trace the issue up to the following inconsistency. Assume a score with just 2 measures; we have:

  • Measure 1: no repeat flag, normal end bar line
  • Bar line 1: normal
  • Measure 2: no repeat flag, END end bar line (end of score)

Assume we drop a start-repeat on measure 2 and then we undo.

A) During start-repeat drop:

  1. Measure 2: _repeatFlags = 2; (in call to some undoable function)
  2. Measure 1: _endBarLineType = START_REPEAT; (in call to Measure::setEndBarLineType() here within the ScoreView::dropEvent() function )
  3. Bar line 1: _barlineType = START_REPEAT; _customSubtype = false; (in call to some undoable function)

B) During undo:

  1. Bar line 1: _barlineType = NORMAL; _customSubtype = true; (as the type of bar line 1 is now different from end bar line type of measure 1) (in some undo function)
  2. Measure 2: _repeatFlags = 0; (in some undo function)

Note that:

  • repeat flags are changed in measure 2, and the end bar line is changed in measure 1
  • there is no undo for the end bar line change of measure 1 (step 2) of A) above)
  • should this change be undone, there is already in place code to detect that bar line 1 now has the same type as its measure and to reset its _customSubType flag. (//github.com/musescore/MuseScore/blob/master/libmscore/measure.cpp#L2596 )

The whole point is that step 2) in A) should become an undoable operation. A seemingly easy solution could be turning the calls to Measure::setEndBarLineType() quoted above and the other nearby (in layout.cpp, lines 2616-2641) into undoChangeProperty().

However, this is layout code, used for instance also after reading a score or creating new measures and bar lines; inserting all these operations in the undo stack may be a source of more problems.

Hoping this may help,

M.

Reply

• Jul 4, 2014 - 16:45

I still can reproduce on Linux.

I think my post above (#4) gives all the info needed to correct the issue. The only open point is whether using undo...() functions is acceptable or not in layout code.

If some of the core developers could answer this question and the answer is positive, I could easily provide a PR.

Thanks,

M.

Reply

• Oct 3, 2014 - 22:51
Status (old) active ⇒ needs info

Is this still relevant? I can't reproduce using original steps. Although it *is* still the case that after step 2, measure 17 moves down to the next system for no obvious reason.

Reply