Deletion of the first measure removes the time signature in parts

• Dec 3, 2015 - 06:17
S3 - Major

421f366 / Windows7

1) New score for piano -> 3/4 time signature + D (two sharps) key signature
2) Generate parts
3) Delete (Ctrl + Del) the first measure in main score
4) View Part

Result: the time signature is deleted

Note: In the main score, the deletion of the key signature, apparently, is not really considered as a bug currently (see this thread:, but I see a change around last March-April. (Clearly, in early March, the key signature is not deleted after the removal of the first measure in main score)

So, what to think? What is it the expected result?

To sum in images:

- start point:
- after deletion of the first measure in main score:
- in part:
in part.jpg

Note 2 : Issue probably (?) related to this thread: #89376: Time signature has disappeared in the instrumental part


So, for this issue (deletion of the time signature in parts after the removal of the first measure in the main score), I see the same behavior as far I can go back in the time, in May 2014, eg with this Nightly: 56177c3

1) result, after deletion first measure (here, as you see, the key signature remains)
19 mai .jpg
2) in part (no time signature)
result in part.jpg


"NOTE": for the "second issue" (or not?), ie the deletion of the key signature, do I fill a new specific issue, or not?
For that, I notice a change on March 9, 2015, with this commit: 787373a
For fix: #49836: Delete time signature corrupts key signature

I have no strong opinion on whether the key signature is correct or not - as my comments in the thread you reference suggest, I can see both side of this. Probably worth further discussion i forum.

Meanwhile, I will take a look at the time signature / part issue.

Cause of the problem seems simple enough: we are using the "score" variable to loop through the linked scores to process time signatures, but in this line, we are not using that variable, meaning we are operating on the score being viewed ("this") rather than the one for the current iteration of the loop:…

Just adding a "score->" in front of the call to firstMeasure() fixes that.

But, I don't understand why we don't also have problems here:…

We are always calling undoRemoveMeasures() with "this" score, even though the measures we are trying to delete are potentially in one of the linked scores. Looking further into what happens downstream, I guess the undo operation gets the score info from the measures themselves as needed, so no real harm done, but still, it doesn't seem right to me. Changing this to use "score->" doesn't break anything, and somehow feels safer.

I will submit a PR for review that uses "score->" more consistently.