Bad behavior of text added in a horizontal frame included in a vertical frame that can lead to a crash
I'm working in a rather large and complex score for an operetta, and I'm attempting to include the spoken dialogue between the musical numbers. To do so, I've created a vertical text frame to hold the stage directions and lines, and, within the vertical text frame, also a horizontal text frame to contain the character names. (This way, I'm able to create a flush left for the line text.) In the attached document, one such example can be found on page 20. (Tip: search for 2X then scroll up.)
Whenever I'm working in this document, there is significant lagging (program turning non-responsive), which is to be expected considering the size and complexity of the document. The major two-fold problem comes when I'm adding and working with text in the horizontal frame.
1. I right click in the horizontal frame and choose Add>>Text.
2. The window jumps up to the beginning of the score (rather than staying focused on the location of text entry.)
3. I'm still able to type the necessary text, though. After I type the text, I press Esc., then I search for the nearest rehearsal mark and scroll back to my text location.
4. The text I just typed does not appear. I have to enter text edit mode within a text box in the vertical frame, or sometimes just click around between the frames, and eventually the text shows up in the horizontal frame. (Any pre-existing text appears, it's only the new text that doesn't show up.)
5. Approximately 1 in 8 times of doing this process results in the program crashing. It doesn't crash every time, and it doesn't always crash after the same action. (Sometimes it's when the window jumps to the top of the score, sometimes is when I'm trying to get the text to appear in the horizontal frame, sometimes it's another moment.)
5b. Sometimes, when the window jumps to the top of the score, the whole page goes blank. For a moment, I can still scroll, but everything has disappeared. Although this blank page view doesn't always happen, when it does, it always results in a crash.
| Attachment | Size |
|---|---|
| Cox_and_Box_Full.mscz | 327.1 KB |
Comments
I can confirm globally the issue. Frequent crashes is not really the more appropriate term, but I can receive sometimes them after various maneuvers (attempt to cut text, move horizontal frame, undo/redo and so on ) with text included in vertical/horizontal frames.
Edit: right now, I fail to receive blank pages.
I see above all two problems (don't know for now if intimely related or not) Maybe would be better to separate in two issues. Will see later.
A ) Score jumps to the beginning of the score
Steps:
1) Load this test file (SATB template 65 measures) : text frames.mscz
2) Go to and select measure 41
3) Insert vertical frame
4) Right-click vertical frame -> Add -> Insert horizontal frame (and resize/reduce it if wished, nevermind)
5) Right-click horizontal frame -> Add -> Text
Result: jump to the beginning
After checking, I see a change on October 2019.
With this nightly, October 29, ff43723, the jump doesn't occur.
But it arrives in October 30, with this one: 438ab6b
There is a few commits between them: https://github.com/musescore/MuseScore/commits/3.3.1
Don't know where its begin (or maybe viewports changes, in last mentioned commit, even there is no parts here ?), but again, just like this.
The "second" problem (B) is worse - I guess it's the real cause of possible crashes - and more former (related to text which disappears - rather don't appears - when added in horizontal frame/vertical frame). It seems working more or less in June 2019 (but rather less than more!) Necessary further investigation.
Problem B )
(realized with nightly of October 29, 2019: ff43723)
So, same steps than in previous comment (no problem here with the jump) +
6) Attempt to input text into the horizontal frame.
The first attempt fails: the text doesn't appears in first intention. But it do when trying to add text into the vertical frame.
(no crash on this GIF, but I received one just before, after a few attempts to delete the text - difficult task anyway!)
See:
I can confirm the problem as well, thanks for the analysis! Seems somehow the text is being added to the wrong page internally, not totally sure why.
Meanwhile, though, just a suggestion: you probably don't really need a horizontal frame for what you are trying to do. It would probably work to just add the text elements to the vertical frame directly, and position then individually.
In reply to (No subject) by Marc Sabatella
Unfortunately, I don't have any more good clues. As far back as I go (e.g. February 2018), the behavior is the same: text entered in a horizontal frame that is itself included in a vertical frame does not appear (just as the "Enter" key has no "visible" effect on the cursor). So it was during the initial development of version 3 that something broke, compared for example with version 2.3.2, where all this works perfectly. A regression then.
In reply to Unfortunately, I don't have… by cadiz1
Thanks for confirming the issue (glad to know it's not just me...I don't mean that in a bad way! haha) and thanks also for 'translating' my issue into more appropriate terms for the devs. Looking forward to a fix! :)
In reply to I can confirm globally the… by cadiz1
The blank page thing hasn't happened for a while now (i.e. within the past day). Next time it happens, I'll try to take a screenshot and make note of what precipitated that behaviour.
In reply to I can confirm the problem as… by Marc Sabatella
Thanks, Marc. Yeah, indeed, I thought of that this morning before reading your comment. I'd thought by adding the horizontal frame it would automatically displace the text in the vertical frame, but, of course, it didn't. I don't know why I persisted with the horizontal frame whilst doing essentially the same thing I could have done without the frame. I've been working now without the horizontal frame, and other than the lagging, it's so far working okay (knock on wood).
I'm pretty sure I have identified the root cause of the problem - the horizontal frame itself is not being handled correctly when you add it. In particular, it is missing the information that says what time position it is attached to. Adding that information seems to fix the initial problem adding text and having the view jump, but other problems remain (it's still problematic when you try to delete it). So more investigation still needed on our end.
https://github.com/musescore/MuseScore/pull/6339
Fixed in branch 3.x, commit ef1a4c9734
_fix #307841: crashes and more with hbox within vbox
Resolves: https://musescore.org/en/node/307841
When adding an hbox within a vbox,
we never set its tick,
and as a result other operations that depend on the tick
(like triggering layout) do not work correctly.
This is fixed by overriding HBox::tick() to check the parent.
It was also necessary to alter MeasureBase::triggerLayout(),
as it actually did nothing for hbox-within-vbox,
because it checks for prev() and next() which are nullptr here.
That check is needed to avoid triggering layout for measurebases
that are not yet added to the score.
This problem is solved here by checking the parent,
just as is done for the tick itself._
Fixed in branch 3.x, commit 3ea363287c
_Merge pull request #6339 from MarcSabatella/307841-hbox-in-vbox
fix #307841: crashes and more with hbox within vbox_
Automatically closed -- issue fixed for 2 weeks with no activity.