Horizontal Frame on system by itself at end of page causes previous system to disappear

I can confirm this. At that point the frame no longer fits on the system and should simply be moved down to the next system, but instead both systems simply disappear.

There is no real point to such a frame anyhow, but I could see this happening accidentally for sure.

There might be the need for such a frame for e.g. Lyrics, esp. if you want a columns layout and so can't use a Text Frame
Or for a trailing image
Or to prevent the verticial alignment to happen on the last page of a score

Edit: oops, I missread, and meant a vertical frame...

The max. width before this happens of course depends on the content and number of the measures in the same same system

RIght, I can think of reasons for text or vertical frames at the end of a score, but not a horizontal system all by itself.

Not one of that size at least. In general it might be wanted to 'prematurely' end the system, at a very exact point, and not via 'Last system fill threshold'

A system that only consists of horizontal frames is similar to a vertical frame in that it contains no actual measures. Vertical frames are already handled in the distributeStaves() code; we probably just want to make sure that any system with no measures is handled in the same way. See https://github.com/mattmcclinch/MuseScore/commit/07c56f7.

Seems a good solution to me!

@mattmcclinch Do you make a PR for this or shall I include it in PR #7529 - Reimplement spacers in vertical staves adjustment to make sure all spacers are taken into account?

@Jojo-Schmitz right but even then, it's not a horizontal frame all by itself on the system. The problem only shows up if the frame is literally all by itself. So this would never be a desired end result, but would totally happen while editing, you add the frame, starting adjusting it, trying to make it as wide as possible to make the preceding measures as narrow as possible. The moment you go one step to far with the width, things disappear. If you happen to realize what happened, you just back off one notch again and all is well. But it would certainly be extremely disconcerting it you didn't figure that out!

Anyhow, glad to see the fix is simple.

Issue is partly solved in the latest 3.x branch by PR #7529. Now all staves are visible but the last horizontal frame is ignored and invisible.
Also looking closer into the solution and proposed by @mattmcclinch, this might not work because with this change the horizontal frame will be handled as a vertical frame. This means the spacing above and below the horizontal frame is then defined by the style parameters Vertical frame top margin and Vertical frame bottom margin and the horizontal frame is no longer handled as a "normal" staff.

Also looking closer into the solution and proposed by @mattmcclinch, this might not work because with this change the horizontal frame will be handled as a vertical frame. This means the spacing above and below the horizontal frame is then defined by the style parameters Vertical frame top margin and Vertical frame bottom margin and the horizontal frame is no longer handled as a "normal" staff.

And why is that a problem? That was the whole point of the change that I proposed. What is the purpose of such a horizontal frame or group of horizontal frames on a system with no measures?

No idea what the point of a system with no measures but if somebody wants them they should behave as a staff and obeying the same rules. If not, don't use a horizontal frame but use a vertical frame.
It seems strange a staff with only a horizontal frame starts behaving differently when it is for some reason in a system, without any measure. That's the problem for me.

@Marc Sabatella Actually, the cause is very simple. The vertical staves adjustment uses the skyline the find out what the actual height of a system is.
When a system contains only a horizontal frame, the skyline is empty and the max() method of the skyline returns -1000000 for the south skyline which is used added to the height of the system (= horizontal frame). This is not a problem as long this horizontal frame systems is not the last system on the page because then this strange value result in a far too large space left which is nicely to divided over all existing gaps.

See PR #7776 for 3.x and PR #7777 for master

Commit message lacked the "#".

Oops. Mea culpa.

need a brown bag? ;-)

Two brown bags, I made the same mistake twice ;-)

Automatically closed -- issue fixed for 2 weeks with no activity.