Special Characters: When open in text object, drag and drop is inconsistent

• Jun 11, 2018 - 15:22
Type
Functional
Severity
S4 - Minor
Status
closed
Regression
No
Workaround
No
Project
MuseScore

Windows 7/10. MS 2.2.1, 51b8386

If the Special Characters window (F2) is open in a text object, many of the symbols can be dragged-and-dropped, but in this case they attach themselves to the staff (i.e. notes, repeats, clefs etc. but not letters, numbers or other WP symbols).

Assuming that this is not the intended behaviour, should drag-and-drop be disabled when Special Characters is open in text objects?

See also #273256: Chord symbols: Anomalous entry from the "Special Characters" window.

Comments

• Jun 11, 2018 - 15:22
Title Special Characters: Dragging-and-dropping symbols adds them to the staff ⇒ Special Characters: Dragging symbols adds them to the staff

Reply

• Jun 11, 2018 - 15:24
Title Special Characters: Dragging symbols adds them to the staff ⇒ Special Characters: When open in text object, dragging symbols adds them to the staff

Reply

• Jun 12, 2018 - 17:58

Hmm, I can't reproduce. Can you attach a sample score and precise step-by-step instructions?

If I could reproduce this, I'd almost consider it a feature, since it sure would be nice to be able to attach resizable symbols to notes etc (elements added from the regular Symbols palette are not resizable). Of course, it would be better if you didn't need to edit a dummy element to get this.

EDIT: hmm, I see, only works for certain symbols, not sure why. I successfully added a clef this way. It's not editable after that, though - it gets added the same way as a Symbol.

Reply

• Oct 18, 2019 - 19:11
Title Special Characters: When open in text object, dragging symbols adds them to the staff ⇒ Special Characters: When open in text object, drag and drop is inconsistent
Reported version 2.2 ⇒  
Regression ⇒ No
Workaround ⇒ No

For me using 3.3 RC, what seems to be the case is this:

I believe the musical symbols are Symbols in the code, the text symbols are FSymbols. I believe the text symbols don't drop because they are missing from the big switch statement in ScoreView::dragMoveEvent(). It works to double-click, though, so it's probably harmless to add it here too. Will test.

Reply

• Oct 26, 2019 - 09:10
Status active ⇒ fixed

Fixed in branch master, commit 563cd5d76d

_fix #273256, fix #273266: special characters dialog fixes

A number of small issues prevent the special characters dialog
from working properly, especially for chord symbols.
Drag and drop only works with some symbols because FSYMBOL was missing
in the switch statements in dragdrop.cpp.
Text elements can handle drop of FSYMBOL (which is why double-click works),
but they weren't getting to chance during drag&drop.
Fix was just adding those case statements.

For Harmony objects, we also needed to add the handlers
in acceptDrop() and drop() (the latter just passing through to TextBase).
However, accidentals require special handling in Harmony::endEdit() in order to parse.
Code was added recently to do this, but it didn't actually work
(I suspect it did when written, but things changed between then and when it was merged).
I rearranged the code in in Harmony::endEdit() a bit - and added comments to explain.
Basically, setHarmony() needs to be called after the back-substitution
(replacing flat with "b", sharp with "#"),
but the back-substitution needs to happen after TextBase::endEdit() finalizes the text
(actually, if it were possible to substitute before, that would be better,
but do to the way the undo records are munged in TextBase::endEdit(),
it seemed to dangerous to even try).
Bottom line: I do the TextBase::endEdit(), then the back-substitution,
then the setHarmony().
I needed to be sure to trigger a layout, which required a startCmd/endCmd pair
(since TextBase::endEdit() already called endCmd)._

Reply

Fix version
3.3.0