Measure numbers restart from 1 after section break even if the corresponding property got disabled

While fixing that issue it'd be useful to move the right-click properties of section breaks to the Inspector

This used to work in 2.x, so is a regression.
Workaround is to manually set a measurenumber offset to the first measure after the section break

I think I found why. In 2.3.2 MeasureBase::sectionBreak() directly returns LayoutBreak* so doLayout() can access the property of that LayoutBreak. But now it returns bool, so doLayout() can only check whether a section break exists (internally, this is to check whether flag(ElementFlag::SECTION_BREAK) is true), it cannot grab the property of it.

So to summarize, it's the new system of ElementFlag that blocked the access of section break property. Which means in order to fix this, sectionBreak() must return an actual LayoutBreak*, replacing the ElementFlag thing. I don't know if this break of consistency violates the coding principle, and if there's another way to do it, I'm willing to hear it.

Some places to check the code: in master: line 4432 in libmscore/layout.cpp, in 2.3.2: line 1461 in libmscore/layout.cpp, in master: line 164 in libmscore/measurebase.h, in 2.3.2: line 102 in libmscore/measurebase.h.

Actually I already found this issue while doing a big score which needed a handful of section breaks, but didn't remember to get it into the issue tracker.

See https://github.com/musescore/MuseScore/pull/5427.

Fixed in branch master, commit 9f1f540917

_fix #292343: measure numbers restart from 1 after section break even if the corresponding property got disabled

Some calls of sectionBreak() should be changed to sectionBreakElement() so the property can be accessed by sectionBreakElement()->startWithMeasureOne()._

Fixed in branch master, commit 55e759860e

_Merge pull request #5427 from Howard-C/section-break

fix #292343: measure numbers restart from 1 after section break even if the corresponding property got disabled_

And about moving the properties to the inspector, does this mean creating a new inspector UI AND disabling the access to them by right-clicking and popping-up a dialogue?

This makes me wonder why some elements have their properties in pop-up dialogues while others have theirs in the inspector right from the beginning...

Yes. Those that still have a right click properties menu are ommissions, not yet moved to inspector

All of them? Things like "Stave text properties" (which has quite a lot of options in four tabs) also?

Good question...

Inspector is used for convenience purposes (I think), and moving styles this many into it won't look good, but styles like section break's can definitely move into because there're only three...

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