-
Notifications
You must be signed in to change notification settings - Fork 3
Many operation create undo entries although nothing was really done #14
Comments
Hmm... cannot verify this. I loaded a map into the editor, clicked int the XY View, but the map name (with full path) in the main window's title area does not add an asteric ("*"), denoting you need to save due to changes. Hitting Ctrl+Z will not really let you test if "internally" a new undo event was added. The poster may have been looking into the source code? |
I verified this with 1.4/1.6, try these steps:
Expected: undo last brush creation operation Result: brush is still there, press CTRL-Z again, now it's removed |
Verified your steps. Creepy. |
This applies to various other operations too, e.g. x-axis flipping without selection creates an undo entry. Basically, many operations working on selection do not check whether there's really something to work on but simply create an undo entry an operate on an empty selection. In c411c8a I introduced Select_HasSelection() which can be used to check this before performing the action. |
This introduces function is nice, but has a shortcoming: there are operations which do not strictly depend on "is there a selection at all", but require e.g. exactly two brushes selected. Others may fail for various reasons other reasons and bail out in the middle. Still, those functions are surrounded by Undo_Start/Undo_End . I guess the right fix would be to detect Undo_End whether there was actually a real modification done and discard the entry if not |
Closing this one as it's too generic anyway. I've fixed some of the undo bugs, need separate issue for remaining bugs. |
E.g. having a selection and just clicking in the 2D view
The text was updated successfully, but these errors were encountered: