Chord symbols: Anomalous entry from the "Special Characters" window
Windows 7/10. MS 2.2.1, 51b8386
- If you have the Special Characters window open in a chord symbol, double-click entry of symbols is disabled. And dragging doesn't work either: symbols are added to the staff rather than the chord symbol text.
- It seems inconsistent that the Special Characters shortcut, F2, works in chord symbols, but there is no text editing toolbar at the bottom of the document window showing a "Special Characters" button.
(Edited)
Fix version
3.3.0
Comments
Why forbid this? I don't see a bug here, at best a feature request.
OTH the ability to add the flat and sharp symbols (and some more) here (rather than the letters b and #) has been requested before, see https://musescore.org/en/node/269352 and https://github.com/musescore/MuseScore/pull/3461
Deleted.
Ah, I see, F2 brings up that dialog, but it doesn't work at all, indeed looks like a bug.
I'd rather make it work though than disallowing it
Edit: why did you delete your post, it was perfectly valid IMHO
Edit 2: Ah, I see you daaded the info to the initial report (or I missed it there the 1st time)
See also #273266: Special Characters: When open in text object, drag and drop is inconsistent.
We're just missing the necessary code to allow this in acceptDrop() and drop() for Harmony elements. When I add it, all seems to work. Not sure it necessarily always does what one would expect in terms of the parsing of the chord symbol, but for RNA, there is no parsing, so it should always be safe there. Will probably submit a fix soon.
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)._
Automatically closed -- issue fixed for 2 weeks with no activity.