InstrumentChange elements appear above top staff rather than staff to which they were attached

• Apr 18, 2014 - 06:41
Type
Functional
Severity
S4 - Minor
Status
closed
Project

Windows 7, GIT commit: a722cfd

1) create score for two or more instruments
2) drag InstrumentChange element from palette to any measure in any staff but the top one

Result: the text is attached to the top staff instead of the one you dragged it to. However, if the score contains any actual notes, the instrument change *does* affect the correct staff, even though it appears above the top staff. And if you generate parts, the instrument is attached to the correct part.


Comments

The issue appears to be the ON_STAFF flag is not set for INSTRUMENT_CHANGE elements. I see it was only added for STAFF_TEXT elements a couple of months ago, so I'm guessing that it was an oversight to not also include it for INSTRUMENT_CHANGE. Other similar text elements set this flag. Copying the setFlags call from the staff text constructor to the instrument change constructor fixes this issue.

But I admit I don't fully understand the purpose of this flag. It appears to play a role in making sure that segment-attached elements can be laid out relative to their logical staff, as controlled by Element::pagePos(). So a text item can have its pos relative to its own staff. That makes sense. But since it seems to be new, I guess it wasn't always done this way.

Harmony objects appear to be treated quite differently. They don't set this flag, so they are laid relative to the top staff at all times. They just have a pos that pushes them sufficiently far down the system. Is there a reason for this? Is that how all text items were stored before the addition of the ON_STAFF flag? Should Harmony elements be converted to this scheme, or is it best to let them be?

Yes. Calculating pos for Harmony relative to top of system *could* have still worked, but the code wasn't accounting for everything correctly. The PR above changes Harmony objects to use ON_STAFF like other text elements, and this required further changes in the layout relative to fret diagrams, but bottom line, it works as expected for me now.