Weird behaviour on editing existing textual elements

• Aug 3, 2012 - 23:49
Type
Functional
Severity
S2 - Critical
Status
closed
Project
MuseScore

I searched for a similar bug report as I presume this has been noticed by someone else, but I could not find it. If my search was faulty and it exists, I apologize.

Status: Github source (commit 2e84a7e of 2012-08-02) compiled with Qt SDK, Qt lib 4.8.0, under Ubuntu 11.10.

Steps:
1) Open any score
2) Start editing an existing (i.e. previously entered) textual element of several (all?) kind; I tried tempo texts, lyrics, harmony, figured bass and texts in a frame; editing could be started both by selecting the element and pressing [Cltrl][E] or by double clicking it.

Results:
1) The 'blue box' appears but no cursor is shown
2) Any change to the text is not displayed
3) When selecting ([Shift]+arrows) no selection appears
4) By exiting edit mode, starting editing of some other text and exiting it, changes to the previous text appear, but this also shows that:
5) The text has been duplicated: one copy with un-edited text and one copy with the edited text

Note: Issue marked as critical, as result 5) above leads to data corruption.

Analysis:
When text edit mode is entered, a copy of the text is created: the copy is edited but the original is displayed; this is the reason why changes are not shown during editing.

This can be seen with a breakpoint in function Text::draw() (file libmscore/text.cpp): the _editMode flag is never set in drawn texts (because the drawn text is not the edited copy).

In addition, it seems the undoChangeElement() function (or similar; undo mechanism is rather complex) does not replace the original with the edit copy, but adds it; however, I have no solid evidence of that, beyond the resulting actual duplication.

M.

Comments

• Aug 4, 2012 - 09:27

Yes, I think I noticed this last night.

However, I don't think it's limited to existing elements?

1. Create score.
2. Click on bar rest.
3. 'Stave Text'.
4. Type something.

Result: Nothing appears.

5. Click page.
6. Click or drag where the stave text was.

Result: Nothing is selected, so the page moves.

7. Enable 'Note Entry'.
8. Input note.

Result: Text appears.

Discussion: Moving or entering elements (at least notes or text?) will make text appear.

Using MuseScore 2.0 Nightly Build (2e84a7e) - Mac 10.7.4.

Reply

• Aug 5, 2012 - 10:44

I cannot replicate chen lung report: with the steps listed above, I see the text while typing, once out of edit mode the txt is visible, selectable and draggable, and so on. This applies to both staff text and system text (which is exactly the same as a staff text except for the "system" flag which is on).

I do confirm my report at the beginning of this thread: once entered, re-editing existing text is almost impossible and the text element is duplicated.

Using rev. 16c2419 of this morning self-compiled with Qt SDK / Qt lib 4.8.0 both under Win 7 and Ubuntu 11.10.

M.

Reply

• Aug 8, 2012 - 13:37

I'm responsible of this weird behavior with this small commit ae02199b05
This commit is legitimate since without it, the BSPTree is computed for each ScoreView::paintEvent(), a bif performance drag.

Reply