I'm going to implement this instead as tracking when changes have been made to the edited unit, and if you try to close or reset the unit in some way, it will mention that there are unsaved changes and ask if you wish to save them. I have a plan for implementing this and I've begun making the necessary refactoring changes in [r1522] and [r1523].
The plan is basically to not pass any Entity references. Instead, I will make an EntitySource interface that specifies an entity accessor. Then MegaMekLabUI will be the ultimate holder of the Entity instance, and when its accessor is called, it will set a dirty flag, and when the Entity reference there is changed, it will check the dirty flag to see if the unit should be saved.
[r1523] was the last piece of the refactoring pie. Now, every place that needs to modify the current Entity instance, ultimately retrieves it from MegaMekLabUI. The plan now is to modify MegaMekLabUI.getEntity() to set a dirty flag. And then use the state of that dirty flag to see if the entity should be saved or not.
In hindsight, I should've thought this idea through more thoroughly. I knew that setting the dirty flag when the Entity accessor is called would have some false positives, but in reality it has way too many. Just the action of refreshing the header (which would indicate to the user whether there are unsaved changes), causes the dirty flag to get set. In the end, the flag was set way too often for this implementation to be useful.
In [r1526], I went with what the RFE suggested: when you try to exit it pop-ups up an "Are you sure?" dialog and if the user clicks no, MML doesn't exit.
I'm going to implement this instead as tracking when changes have been made to the edited unit, and if you try to close or reset the unit in some way, it will mention that there are unsaved changes and ask if you wish to save them. I have a plan for implementing this and I've begun making the necessary refactoring changes in [r1522] and [r1523].
The plan is basically to not pass any Entity references. Instead, I will make an EntitySource interface that specifies an entity accessor. Then MegaMekLabUI will be the ultimate holder of the Entity instance, and when its accessor is called, it will set a dirty flag, and when the Entity reference there is changed, it will check the dirty flag to see if the unit should be saved.
Related
Commit: [r1522]
Commit: [r1523]
Last edit: Nicholas Walczak 2015-04-09
[r1523] was the last piece of the refactoring pie. Now, every place that needs to modify the current Entity instance, ultimately retrieves it from MegaMekLabUI. The plan now is to modify MegaMekLabUI.getEntity() to set a dirty flag. And then use the state of that dirty flag to see if the entity should be saved or not.
Related
Commit: [r1523]
In hindsight, I should've thought this idea through more thoroughly. I knew that setting the dirty flag when the Entity accessor is called would have some false positives, but in reality it has way too many. Just the action of refreshing the header (which would indicate to the user whether there are unsaved changes), causes the dirty flag to get set. In the end, the flag was set way too often for this implementation to be useful.
In [r1526], I went with what the RFE suggested: when you try to exit it pop-ups up an "Are you sure?" dialog and if the user clicks no, MML doesn't exit.
Related
Commit: [r1526]