Minor annoyance: Basic clicks create tons of Undo history

[dgoyette]

I was finding that it was taking a lot of ctrl-z to undo a change I made to a cutscene. Looking into this, it appears that basically any mouse click anywhere in the slate editor generates another Undo History record. The most obnoxious example of this is clicking around on the time scrubber to jump to different times in the cutscene. Every click generates another Undo record, meaning that it could take a huge number of ctrl-z to actually undo the last meaningful change. Even things like clicking Play and Pause in the slate editor will create undo history.

I see the code that’s doing this. I’m not really sure how a single click can change the cutscene, and deserves to generate undo history. (Drag operations, sure, but not single clicks). Any good reason I’ll regret disabling this line of code, forcing it to false? I imagine there’s some gotcha here that forced this approach, but so far I don’t see it:

`var doRecordUndo = e.rawType == EventType.MouseDown && (e.button == 0 || e.button == 1);

[Gavalakis]

Hello. This was added as a fallback because not every single GUI action has undo recorded (from what I recall some were not possible at all), BUT you are right, this is not optimal. This is something I want to remove as well once I look again at handling recording undo for those GUI actions I initially had problem with. Removing the line on your end now will cause some GUI actions in the Cutscene editor to not be undo-recorded, and as such performing an undo may result in multiple things being undo-ed at once (which can be confusing).

Thank you for the reminder of handling this better.

Join us on Discord: https://discord.gg/97q2Rjh

[dgoyette]

Thanks. I ended up messing around with this a bit, and modified my local code such that mouse clicks just on the scrubber region (topMiddleRect) don’t trigger ‘doRecordUndo’ to be true. So far, I haven’t found any strange undo behavior, but I’ll keep an eye out for it.

[Author]

Posts