Able to open backup files as an import

• Oct 15, 2019 - 11:38
Type
Functional
Frequency
Once
Severity
S5 - Suggestion
Status
closed
Regression
No
Workaround
No
Project

Episode 3 of Backup File Improvements series as discussed on Telegram ;-)

Turns out to be much harder than I thought, for example I can't figure out what code makes treating opening files from 2.3.2 or older versions as importing (because you have to do Save As if you want to save it in MuseScore 3). I want to do in a similar way for a backup file: opening it as score and forcing Save As.


Comments

Another question: how do I actually import a file from a different format to score, but without creating a hidden file having the .mscz/mscx suffix or things as such (using my current knowledge I can only think of renaming the .mscz/mscx, into .mscz/mscx and go through the score-opening process)? ImportMidi does that quite well: it converts a midi file to a score but doesn't create another file in the folder. What code realizes that?

If you're forced to do a 'Save as' (like when using setCreated(true); and setAutosaveDirty(false);) no backup would be created, as far as I know

Once opened/imported, "the score" is an object in memory, not a file on the system itself. Saving the score means writing (whilst possibly also converting) that memory structure into a file.
As Jojo mentioned, turning of autosave for this opened/imported file should also prevent any further file creation until an explicit save is issued.

In reply to by jeetee

Thanks! I opened the score.

But saving is bugged, if I save in mscz format, the file name will be "file.mscz,.mscz"; if in mscx format, the name will stay the same, "file.mscz,", no ".mscx" is added. The only thing I found probably relevant is doConvert(), but it's a static function never used in the entire solution (don't know why it still exists). Do you have any idea?

there are 2 doConvert() and both are being used, once each, one inside the other actually.
I don't see how those ratelt to the problem at hand here though.

Yes, you'd need to strip off that .mscz,. There is completeBaseName() which should help getting rid of this?

Fix version
3.5.0