note added to wrong staff if entering note input mode after selecting element attached to invisible staff
Priority
P2 - Medium
Type
Graphical (UI)
Severity
S4 - Minor
Status
active
Regression
No
Workaround
Yes
Project
In this score Wrong_staff.mscz
select the rehearsal mark "A"
Save score (I used ctrl-S)
press N for note entry - All looks normal to this point.
enter a note
result: note is entered in the invisible flute staff rather than Oboe
Expected result: note should be entered in the first visible staff - the oboe.
Comments
Saving doesn't seem relevant. Even without a save I get the same. The issue seems to be that an element (the rehearsal mark) is selected that is attached to an invisible staff, so when we enable note input mode, we are trying to enter onto that staff.
I discovered the bug while saving, so I repeated the steps that led me to find it. There were other problems fixed that were related to the instruments windows and crashes, so it seemed logical to me that the save might be the culprit since this had not been previously reported. I wonder if other system elements lead to the same results. I'll have to check it out. In any case, MS should realize the staff is invisible and move down the list until it finds one that is not.
Tempos, segnos, all reapeats and jumps except measure repeat and swing marking have the bug
Voltas and key signatures do not have the bug, they are just annoying because they jump to the first measure of the song.
time signatures, barlines and frames are normal
Any other system items that could be affected by the bug?
I believe any element that is attached to the invisible staff will show the problem. That will include any form of system text including tempo markings etc. It also includes things like if you actually select a frame, since those technically show as being attached to the top staff even though they aren't really attached to any staff at all.
Time signatures et al aren't affected because they aren't attached to the invisible staff. I mean, the invisible staff has a time signature, but it's invisible also, so you can't select it. Only the things that are attached to invisible staves but still display - like system text - will be selectable, so only those things will trigger the problem.
I believe this was a result of our trying to be more forgiving about allowing people to enter note input mode without first selecting something reasonable. You're supposed to have to select a note or measure, but a request was made to allow note input mode if you select something else first, so we added code to try to figure out which staff / measure to start with in such cases.
Wouldn't be hard to fix by putting up the "No note or rest selected" dialog. Actually figuring out which staff to use and using that would be the better fix, though.
Step #4 is: enter a note: with the keyboard.
No issue by entering the note with mouse. Or, by entering the first note with mouse, and the followings with keyboard
Or, better: by selecting first the measure or rest -> "N" -> input notes with keyboard
Is this a 2.1 regression?
I don't have 2.0.3 installed at the moment. But my sense is, the change we made was done either since 2.0.3 or maybe between 2.0.2 and 2.0.3. Before the change, attempting to select a rehearsal mark then entering note input mode would simply have failed completely, most likely with a dialog telling you to select a note or rest first.
See #46701: when object other than notehead, rest or measure selected, note entry starts at measure 1. Apparently, the old behavior was note input would jump to measure 1, and it looks like that is probably how it was through 2.0.1, but the change was made between then and 2.0.2. Perhaps someone with access to older versions can verify?
Indeed, before the mentioned issue above, the note input jumped/began to measure 1.
But, basically, this behavior (ie without first selecting a measure before note input in a visible staff / or by typing first with keyboard, the notes are added in the invisible staff), I see it, exactly the same, in the last years, and until in 2014, with this nightly: 56177c3
Which means not a regression but an issue with 2.0.3, 2.1 and master
Relates to #285237: [EPIC] Invisible staves issues