Skip to content
This repository has been archived by the owner on Jun 16, 2019. It is now read-only.

Many operation create undo entries although nothing was really done #14

Closed
mfn opened this issue Jan 5, 2010 · 6 comments
Closed

Many operation create undo entries although nothing was really done #14

mfn opened this issue Jan 5, 2010 · 6 comments

Comments

@mfn
Copy link
Owner

mfn commented Jan 5, 2010

E.g. having a selection and just clicking in the 2D view

@AEonZR
Copy link
Contributor

AEonZR commented Jan 5, 2010

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?

@mfn
Copy link
Owner Author

mfn commented Jan 5, 2010

I verified this with 1.4/1.6, try these steps:

  • Start with a fresh map
  • Create a brush, de-select
  • single-click somewhere in 2d view
  • press CTRL-Z for undo

Expected: undo last brush creation operation

Result: brush is still there, press CTRL-Z again, now it's removed

@AEonZR
Copy link
Contributor

AEonZR commented Jan 5, 2010

Verified your steps. Creepy.

@mfn
Copy link
Owner Author

mfn commented Jan 5, 2010

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.

@mfn
Copy link
Owner Author

mfn commented Jan 5, 2010

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

@mfn
Copy link
Owner Author

mfn commented Feb 1, 2010

Closing this one as it's too generic anyway. I've fixed some of the undo bugs, need separate issue for remaining bugs.

This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants