Regression: inability to change a clef inside a system leads to crash
GIT commit 292a8d9 / Windows7
1) "My First Score"
2) Drag and drop the bass clef in measure 3 (hightlighted)
Expected result:
Current result: the bass clef is not added (or, it jumps directly to the second system?)
Same for other systems of course.
And also, by other means: ie by hightlighting the whole rest of the measure. Or, by double-click (ditto by select first the measure, or the rest)
Last observation: by adding a clef in the first measure of the second system (and followings), the courtesy clef is not a the good size (ie the same size than the main clef)
Comments
I see the opposite effect, opening a 2.0 score that didn't have such a mid measure/staff clef now has one, not sure whether that is related.
And adding a clef to "my first score" here causes a crash (maybe because it is a DEBUG build?), due to a failed assertion:
Fatal: ASSERT: "e == 0 || e->type() == Element::Type::CLEF" in file ...\MuseScore\libmscore\element.h, line 813 (:0, )
Likely introduced by excatly that commit with deals with 'cleanup drag&drop'
Applying a clef to a note or rest (rather than to a measure) does work, but always does apply to the 1st note/rest rather than the one it got dropped on.
When applying a clef to a a full measure rest via double click, it crashed, again with a failed assertion, but a different one:
Fatal: ASSERT failure in QVector::operator[]: "index out of range", file C:/Qt/5.6/mingw49_32/include/QtCore/qvector.h, line 427 (:0, )
Me too I can get crashes. But really very instable (not systematically, and in different scenarios). The behavior was worse, more crashes, or/and (according, too, different things) huge space created in the measure when adding a clef, with the previous nightly: ea88600
This issue, at least, the main problem (no clef added to a measure "inside" a system), is not related to the current nightly: 292a8d9
Rather former/former, from what I see by now. I go to check with more focus.
Fixed in branch master, commit 9f12f2aa7c
fix #139316 Regression: inability to change a clef inside a system leads to crash
Ah, thanks.
![1) 41b 3 juin.jpg]( "1) 41b 3 juin.jpg")
![2) a41 2 juin.jpg]( "2) a41 2 juin.jpg")
![3) 25 octobre.jpg]( "3) 25 octobre.jpg")
But it is perhaps useful to report the result of my observation, for reference (this will prevent to search again, if necessary).
So, I was about to say that the first change took place on last June, 3.
- With this nightly: 41b89ae, result as expected:
But not with this one (clef added, but not to the next system): a41b109
- Then the second change came on October 25, with this nightly: f7d9650 and the result described initially (no clef in the expected location, but jumps to the second system)
Automatically closed -- issue fixed for 2 weeks with no activity.