Unable to Copy/Paste a single selected note/rest with Nigthly

• Jun 28, 2015 - 09:56
S4 - Minor


It's impossible to copy/Paste with last nigthly.

Windows 7

Bye bye




Create a new score.

N 5 A B C D

Select A, Ctrl+C and Ctrl+V in second measure dosen't work.

Doesn't work even if i use Copy/Paste contextual menu.


copy/paste doesn't work with a list selection (and never did, for notes/rests), only with a range-selection.
click on the A, shift+right, shift-left, Ctrl+C, 4*left, Ctrl-V

Hmm, I'm wrong, this did work in 1.3 and 2.0.1

Title Unable to Copy/Paste with Nigthly Unable to Copy/Paste a single selected note/rest with Nigthly

This still is a list selection, with only one element (just like a note is a chord which just one notehead)
Anyway, you're right this does work in 2.0.1 and 1.3, so we're having a regression here

So it is one of these 3 commits that broke it:
dc261b4, 83ae627, 656451f.

dc261b4 is still my favorite, as it is the only one dealing with selections.

Hold on, 656451f too fixes a copy/paste problem, #45356: manual position of a line (8va, cresc., etc.) not preserved on copy/paste

83ae627 fixes something seemingly unrelated, #66776: "V" shortcut does not affect the ties and slurs which extend on the following system

However, I don't see anything obvious in either.

Previously, this only would have worked if you clicked the *rest* in the second measure before pressing Ctrl+V, right? That is, it woudn't work it you select the measure itself? It's probably kind of an accident it ever worked when selecting the rest as the target, but I think it stopped working before of this change of mine:


It is designed to prevent crashes or other bad behavior that results from attempting to paste elements onto targets that are not actually designed to accept the paste, by checking first whether the target will accept the element being pasted. Rests claim they won't accept a note, but in actuality, they do.

We could back out that change of mine - it wasn't needed to solve the problem I was solving, but it seemed it would solve other potential problems. It also had the potential to create situations like this, where something that happened to work before stopped working.

On the other hand, we could fix Rest::acceptDrop() to acknowledge that a note is in fact OK. Chances are there would be other similar similar things to fix too. Might be safer for 2.0.2 to back out this change, but leave it in place for the master and fix the other places where acceptDrop() is not returning good information as they are found.

Adding the line

|| (type == Element::Type::NOTE)

in libmscore/rest.cpp, around line 204 seems to fix this problem. Not sure whether this has other ill effects though.

@Marc: your idea of daisy chain to ChordRest::acceptDrop() does not work: that method doesn't exist

Sure enough! Probably just as well. Adding the line you mention is a good fix if we leave my previous change in place.

The main use of acceptDrop() is, as I understand it, to help the drag & drop code know when to highlight a potential drop target. So if you are dragging something from the palette and your mouse reaches an element, acceptDrop() is supposed to say yes or no according to whether or not it makes sense to allow the palette icon to be dropped there. So for the most part, it is reasonable to expect acceptDrop() to return true for anything that drop() is designed to handle. It just so happens we also use drop() for copy and paste of single selections, and that can occasionally involve elements that would never normally be added from the palette, like notes. So those are cases where there might well be code to handle the operation in drop() in order to support paste operations, even though acceptDrop() does not know to allow it because it would never happen for drag & drop.

As far as I understand the situation, it should still be good to fix any such issues we find where acceptDrop() is out of sync with drop() in that way. Which is to say, anything we allow to be be added to a particular from the palette should probably be allowed via paste and vice versa. However, I have no idea what corner case exceptions might exist where some element really should accept drops from drag & drop but not from paste or vice versa.