mscVersion management

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

mscVersion management

Marc Sabatella
We use mscVerssion in a score file to track the version it was saved with.  Prior to the release of 2.0, we added code to the end of doLayout() to set this to the current version, so that the saved version info is used only during the initial score read & first layout, and then the score is treated as current:

This makes sense to me, and indeed I think it was added after I was running into problems because previously we were *not* setting this until the file was saved.  The result was that we'd see strange behaviors when editing scores scores created in 1.3 that magically fixed themselves if you waited two minutes for the autosave to kick in.

However, this code we added is currently not doing anything in the master to differentiate 206 and 207 - the versions for the 2.0.x series and what will eventually be 2.1.  This is causing me similar issues now, as a 2.0.2 score upon load claims to be mscVersion 206, and this magically changes to 207 only after saving it.  I have some layout optimizations I want to do for hairpins, and some compatibility mode code to make sure older scores aren't affected, but it isn't working right because the score still claims to be 2.0.x even after it is fully loaded and laid out.

I'm thinking we should change the test at the end of doLayout() to bump mscVersion to the current (MSCVERSION) unconditionally, not just for 1.3 and older.  Or at least, change the test to 206 instead of 114.  This would definitely be a help to me with my hairpin code.  I'd like to think that none of the other code that depends on 206 versus 207 would be adversely affected, but does anyone know differently?