Abandon Reload?

• May 11, 2011 - 15:49

I'm not sure if there's an actual need for Reload - it can lead to problems like this:
#10632: Part doesn't Reload, also creates .mscz, and empty tab


Version 1. - 3996 XP.

I find a need for reload more often than rarely.

For example. sometimes a chordname will not delete (apparently) until a reload.

There are also style changes that do not take place until after a reload, so I would like to keep this facility.


I dont like this function. Its not needed. There is an easy replacement by simply restarting mscore. The "start with last session" is made for this.
On the other side its hard/expensive to implement as there are lots of special cases. I also doubt a casual user knows what "reload" does. Its a low level, very technical concept.

My proposal is also to remove "Reload".

In reply to by [DELETED] 3

to keep this feature. Rebooting MuseScore takes much longer. Please wait until the issues that cause a need for this feature are fixed.

I am sure there are many features which casual users do not understand, but that is no reason to remove them.

As far as I can tell, this feature is not causing a problem - why remove it?


In reply to by xavierjazz

That's the part that makes "reload" a strange command, to me in the same league as "Save as copy" - commands I don't see a need for but some do. If you don't save the changes, it will reload the original, but if you do, you don't get the chance to rename (so the changes are saved to another file) and the original is destroyed, negating its usefulness.

To me, the program logic behind Reload should not be that hard, but maybe the implementation inside of MS is different than what I expect. That's why I asked Werner what MS actually does when Reload is invoked (or what it was intended for) and why it is so problematic.

In reply to by schepers

Reload allows to abandon all changes made in the current session and "start over" with the copy on disk.
Saving and then reloading makes no sense.
There are some special cases which are possibly not handled right: scores with parts, new created scores and the interaction with the autosave mechanism.

A more sophisticated solution would be to implement a full blown revision system (for which some hooks are already in the code). This would allow to define arbitrary revisions (at least every session would create a new revision) and to go back in history.

In reply to by [DELETED] 3

Either I don't do very complex scoringwhich requires revision control (which is likely) or my experience over the past 30 years with many applications has given me a more jaded view of things as I tend to do things very old school. If I need to keep track of file revisions, I will periodically save what I am doing to a new file so I have a logically ordered file chain, properly numbered or dated, etc. If I want to abandon what I am doing, I close without saving and open a previous version. That way _I_ know what is happening and am not leaving things to some multi-facted program command.

I vote to remove it as well.

In reply to by schepers

I have been writing a number of lead sheets.

I have had to use reload at least 15 times because of the score not displaying properly after doing things like:
1. removing a chordname.
2. raising or lowering a note via the up/down keys.

I may be the only one but I NEED this function until these artifacts are fixed.

XP Pro, r3996.


Do you still have an unanswered question? Please log in first to post your question.