Text in textframe disappears with Ctrl-C

• Dec 7, 2016 - 22:38
Reported version
2.1
Type
Functional
Severity
S4 - Minor
Status
closed
Project

Open "My First Score":

1) press Esc twice to make sure nothing is selected
2) Replace title with "This is a test"
3) right click the title box, being careful *not* to first select it (so it is still black)
4) select Edit Element from the context menu
5) hit Home & Shft-End to select the text (It is now inverted, as in classical selection)
6) press Ctrl+C

Result: a missing glyph replaces the selected text.

(Note: This came about because I did not realize I could select the text by double clicking it)


Comments

I can on Windows with 2.0.3 as well as current master. BTW, step 2 is not needed.

I am guessing somehow the state On Mac, do you find the text remains unhighlighted (still black) when you right click it? How about when you choose Edit Element? For me, everything stays black.

For me, Ctrl+C and Ctrl+X both fail, but Ctrl+V works, oddly enough. So do the various other text-specific shortcuts like Ctrl+Shift+f to enter the special "f" dynamic glyph, Ctrl+right arrow to advance to the next word, etc. I'll try looking into it further.

So far, I can only say that Ctrl+C is not invoking the copy command. Under normal circumstances, the place where processing starts (coming out of the event loop) is in ScoreView::editCopy(), which gets called from a switch statement in the generated (?) function ScoreView::qt_static_metacall with an id of 28. But this just doesn't get hit at all in the bug case - there is no call to qt_static_metaCall to start the ball rolling. Instead, we end up in Text::editInserttext(), because we actually start the processing with ScoreView::editKey(), which never normally gets hit for me on pressing Ctrl+C. Well, it gets hit when I press Ctrl, but nothing special happens yet, and when I complete the action by pressing C, we don't hit editKey() again.

Unfortunately the whole event loop processing stuff ion Qt is still largely a mystery to me.