mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-09-28 04:54:13 +02:00
ispyisail
ae6b992ae4
redo() has a direct-write path guarded by m_first_time: on the very first call it writes the property immediately, and only animates on calls after that (per setAnimated()'s documented contract). undo() had no equivalent -- it always animated, so undo() both returned before the property was restored (stale state visible to anything sharing the call stack) and, with no running event loop, never restored it at all. The obvious fix -- reuse m_first_time in undo()'s guard too -- turns out not to work, and I verified this with a standalone build before picking an approach: QUndoStack::push() always calls redo() once before any undo() can run, and redo()'s direct-write branch sets m_first_time = true as it completes. So by the time undo() is ever called, m_first_time has already flipped, and reusing it would make undo() take the animate branch on every call, unconditionally -- syntactically symmetric with redo(), but behaviourally unchanged for the exact scenario reported. Instead, undo() gets its own m_undo_first_time flag, seeded from the same first_time argument setAnimated() already takes, and set true by undo()'s own direct-write branch the same way m_first_time is set by redo()'s. That gives undo() a real, reachable direct-write path on its own first call, independent of how many times redo() has already run. Verified against a standalone build of just this class (as the issue's own repro does): first redo and first undo are both now synchronous with no event loop running; with an event loop present, both settle to the correct value once "broken in"; behaviour for every other caller of QPropertyUndoCommand -- everywhere that calls plain enableAnimation() or the bare setAnimated() (first_time defaulting true) -- is provably unchanged, since m_undo_first_time starts true either way and the animate branch never modifies it. Fixes #755.