Page settings in parts are initialized incorrectly in dialog if using pre-3.5.2 defaults

Confirmed. Somehow this would seem to relate to the issue fixed in 3.6.2 where style settings from the score would apply to the parts on reload, but that might be just coincidence that the symptom seems vauegly similar.

Something else, though - while the left/right margins are not being saved properly, somehow the top margin was changed even though I didn't change it. It still says 15, but somehow it does look different before/after.

So far I'm struggling to reproduce this in a score I create myself, so I am thinking somehow the trigger has to be something about how this one was created. Was it originally written in an earlier then imported into 3.6? Anything else unusual you can think of that could explain why i see the problem here but not elsewhere?

Here's another strange thing in this score: when you load it into 3.6.2, even without making changes, the margins in the parts really are 10mm already. You can see it's equal on the left and right side of each page. The dialog appears to be completely lying about the margins when it reports them as 15 & 5. Also, if I change the margins to anything but 10 & 10, they take just fine - you see the effect, and it survives save / reload. Only setting them to 10 & 10 fails in this way. It can't be coincidence that 10 & 10 are the margins in the score itself.

Again, I can't reproduce any of this in a score I create myself, not yet anyhow.

Did you import this directly from 2.x into 3.6? If so, can you attach the 2.x version? Or, if you imported it into a previous 3.x version, can you attach a version from before you imported into 3.6?

Right now I can still don't understand if this problem is unique to this score - like I said, I cannot reproduce it with any other - or if it's a problem that will occur with any score in which the same steps were followed. That's why understanding the steps that led to this is so important.

Righr now what I can tell you is the page settings dialog is lying to you - the margins really are correct already, 10mm on both sides. And the page settings will allow you to change the margins to any other value you want - 15 mm, 50 mm, even 10.01mm. The only value they refuse to show in my testing are 10mm, and I assume that's related to the fact that these are also the score margins. But again, where the dialog shows it or not, the margins are correct, so it's hopefully not quite as serious an issue as it first appears.

@Marc Sabatella the OP wrote The first creation of this was using version 2.x. I have been editing using v3.x and I didn't experience this issue before using v3.6.
so created in 2.x, imported into 3.x, pre 3.6, then 'imported' into 3.6...

3.4.2, to be exact.

Thanks, this gives me a better idea as to what is going on. I'm not 100% there yet, but I note a few things here:

• loading the v2 file into 3.6.2, if I answer "yes" to the reset question, I get the same problem (page settings preview does not reflect reality, for the parts)
• if I choose to Reset All Styles to Default, the problem goes away, or at least goes into hiding (there may be a way to reproduce still)

I think the fact that 10mm is the current margin in the score is not the reason this one value seems to cause problems in the parts. I think it is the fact that 10mm was the default value prior to 3.6 that is causing this setting to not show in the dialog correct. My guess is we're seeing this value as being the default and are thus not bothering to copy it to the preview score in the dialog (and the preview score is the key, everything in the dialogs works on that).

So I can now reproduce this from scratch. It's just a matter of creating the score and parts in 3.5.2 or older and leaving all margins at their defaults. Loading the score into 3.6 and keeping old style, you'll see the score shows correctly as 10mm in page settings, but the parts report as 15mm even though that isn't really true. And if you then try to change to 10mm and save, on reload you'd see the lopsided 15/5. That's because MuseScore is getting the printable width right but getting the left margin wrong - 15 instead of 5 - then using those two values to calculate the right margin.

But it's important to emphasize - the margins in the parts are actually correct at all times, it's only the dialog that is wrong. That is, if you don't open the page settings dialog, the parts will have the same margins they did in older versions. If you do open the dialog, any settings you make there do apply to the parts, and they do get saved. So when you reopen the score, those margins are correct. It will just look like it's wrong if you open the dialog again.

So if want to keep the original margins, you are good - just don't bother opening the dialog. If you do choose to open the dialog for whatever reason, though, you need to be careful to set all values to what they should be before hitting OK, otherwise the new wrong values will now take effect. So, you can't just change the left margin, you need to change all margins to the values you want, since the values being shown in the dialog are incorrect.

https://github.com/musescore/MuseScore/pull/7514

Fixed in branch 3.x, commit 1874603fb7

_fix #317272: page settings dialog shows wrong values in pre-3.6 parts

Resolves: https://musescore.org/en/node/317272

When displaying the page settings dialog,
we create a preview by cloning the score,
and the dialog actually manipulates the preview's values.
However, the clone is always forced to current style defaults,
so for pre-3.6 scores that, the preview and the spinboxes show
new 3.6 defaults as opposed to the old.
This causes the preview to display completely unlike the actual score,
and it also means the default values for the margins are wrong.

A full fix for this would involve re-examining the logic used
in the clone() methods for both Score and MasterScore.
But there could be any numebr of side effects to this.
So the fix here is very conservative:
it just overrides the clone's style with the original style
after the fact.
Thus is can only affect the page settings dialog.

It should also be noted this bug only affects parts, not parent scores.
That is because the process of reading/writing the parent score
resets the style again based on version tags encountered.
So probably there is another fix here involving that logic.
This too would almost certain have side effects._

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

reopening as this seems needed for master too

I have what may be a related issue but may just be another page settings issue.

I just imported this score (Swing_Lake.mcsz) to 3.6* after previously importing it from 2(.5?) (Swing_Lake1.mscz) to 3.5. I'm trying to readjust the formatting of the parts. For most of the parts, I've had no problems. However, for the Tenor 4 and Bari 5 parts, the "Page settings" preview does not match the formatting once I exit "Page settings" (or click "Apply").
- If I save and reopen the score, the part is unchanged. Also, the preview is also unchanged (different from the part).
- If I save the part (Swing_Lake-Tenor_4.mscz), the part resembles the Page settings preview and the preview matches the part.

If you load the current score and the Tenor 4 only score, then use split-screen to compare the two parts, the size from the score appears smaller, at least judging by the number of measures on the first staff of each. The "Page settings" preview for both look the same, though I didn't do a side-by-side comparison.

Another anomaly with this score which may or may not be related - every time I load the score, MuseScore immediately must change something because the score is starred as modified.

If either of these are deemed as separate issues, I find them as Minor in that I can work around the first with minor difficulty and I can ignore the second since I cannot even find what MuseScore appears to have changed.

Notes:
* OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.6.2.548021803, revision: 3224f34
I did not use Forum for this primarily because I do not hold the copyright to the music, but only have permission from Mr. Checket to have and use the music.

The latter bit is by design, the thing that is changed upon importing older scores is your decision regarding updating them. By saving with the current version you won’t be asked again.

The basic issue with page settings sounds likely to be the same issue as the one here indeed, but I’m not currently in a position to be able to investigate further, And in any event, this whole import process will undoubtedly change for MuseScore 4.

Thank you for the reply, but that score was already saved with the version of MuseScore that I'm using. I'm familiar with importing from a previous version. This has to be something else (my assumption; I've seen it on other scores, too) or MuseScore is not recognizing that it has already updated the score.

I've provided my scores in the hope that they might provide further assistance in tracking the problem(s). One assumption I make from programming experience is that, even if the problem seems to be created by an unlikely sequence of events, don't assume that someone won't find another, faster, easier way to arrive at the problem. So, though the import procedure for 4.0 will no longer cause the problem, if the bug is not fixed, some user may manually select options that invoke the bug.

Thanks for the scores! Now that I'm at my computer, I see what you mean about the 3.6.2 score showing as having changed immediately on load. That's not normal, but my best guess is that somehow there is a measure that fit on one system when you saved it but for whatever reason doesn't when you load it again (or vice versa) and that forces a relayout that in turn forces changes in terms of adding clefs at the start of system, changing where hairpins break across systems, etc. None of which is apparent because it's in continuous view. Anyhow, that's my theory based on what I know of how things are structured internally.

Anyhow, I don't think what you are seeing here regarding parts can be related to the issue here because this one affected only pre-3.6 scores. But, it's also conceivable that somehow this is also related to the "asterisk" issue, that somehow some style setting is not being applied correctly.

None of the code involved exists any more in MuseScore 4, so the same exact bug can't exist. but no doubt, it's quite possible and likely for brand new bugs to have been introduced in the rewrite. And indeed, having these scores available will make an interesting test case.