how to tell when an "overlapped" element is selected?
MS 1.1., winxp
When there are two notes or two rests in the same location as can happen often with multiple voices, one of the elements seems to be overlapped by the other and won't display highlighted when it is selected. Is there a way to convince MS to do something like "bring the element to front" so that the highlight shows? And a second question: is it possible to select one of these occluded/overlapped elements by mouse click, rather than by arrowing over from an adjoining element?
Comments
I don't know of a direct way to do this, but I too wish it were possible. What I normally do is double click the one that happens to be on top, move it out of the way, then do what I want to the one that was underneath, then click the first and hit Ctrl-R to reset its position.
In reply to I don't know of a direct way by Marc Sabatella
yeah--I've been moving occluding notes by an octave as a quick way to reveal the underlying note and still easy to move back later. I didn't know about ctrl-r -- that could come in handy for a variety of other situations--thanks.
For my main question about how to tell what's selected I have two thoughts/suggestions:
1) in addition to changing the color of the element itself, MS could extend the colored area to surround the selected element. That would at least give a visual indication that there is an underlying element that is selected.
2) in graphics applications that allow you to move/overlap objects, there is often a "send-to-front" or "send-to-back" command that would allow re-ordering of how the elements are stacked.
In reply to yeah--I've been moving by mtherieau
Another thing I've see that could be useful is a special ley sequence to cycle between elements. Like, click to select the top element, then shift-click on the same spot to select the element underneath, and each successive shift-click goes down one level. I suspect that would bemore straightforward to implement than a send to back / bring to front command, as that would require MuseScore add a concept of visual layers that it probably doesn't have right now.
In reply to Another thing I've seen that by Marc Sabatella
interesting suggestion. Maybe this "special-click" command could also address a somewhat related issue I run into fairly often, which is the difficulty in selecting small elements attached to notes, like slurs, fingerings, etc. Maybe this theoretical "shift-click" (or whatever button/keyboard binding) could rotate through elements attached to a note, as well as elements hidden underneath. (not having that feature the workaround is, of course, to zoom in -- it's a little cumbersome, but it works)