View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004265||FreeCAD||Bug||public||2020-02-15 10:38||2020-10-17 10:26|
|Summary||0004265: Undo doesn't restore the state as it was before opening a transaction|
|Description||When opening a transaction and adding an arbitrary amount of objects to a document before committing it then the undo should always remove these objects again.|
In v0.19 this doesn't work any more.
|Steps To Reproduce|
=> The body and origin will be removed from the document but the sketch stays
It's possible to edit the sketch (some error messages appear) and as soon as closing the sketch after doing some changes FreeCAD crashes.
|FreeCAD Information||OS: Ubuntu 18.04.4 LTS (XFCE/xubuntu)|
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.19593 (Git)
Build type: Unknown
Python version: 3.6.9
Qt version: 5.9.5
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: German/Germany (de_DE)
Another test case:
Storing the transaction name and id independent of a document messes up the transaction system.
This https://github.com/FreeCAD/FreeCAD/commit/69ea7a3d51d653906d35a86203ce197cf22f73a5 fixes the issue with the remaining sketch on undo.
And this https://github.com/FreeCAD/FreeCAD/commit/8c0dc924269ece2490378889da12636767cd6f9f fixes the disappearance of the fillet on undo
So, what still needs to be fixed is the mess with the active transaction name which is only a medium severe issue.
||Fix committed to master branch.|
The reported mess with the transaction name is not fixed!!!
Another regression is that GUI changes are not recorded any more:
Another odd regression compared to v.018:
In v0.18 you can press undo & redo as often as you like and the box is always updated correctly.
PR submitted to enable transaction on view object. Can't remember exactly, but I think previously view object changes are not recorded?
The Box movement undo problem is an entirely different issue. It happens because the property changes recorded in transaction is unordered, and AttachEngine will recalculate positioning regardless if it is performing transaction.
The non movement happens in undo if Placement is restored first, and then some attachment related property is restored next, which triggers AttachEngine positionBySupport(). Because MapMode and Support have not been restored yet, the placement is revert back, which nullifies the undo.
The reason this problem does not shown up before is because std::map was used to store property changes of each object, with the pointer to the property as the key. When the application starts up, the memory pointer value is likely increasing. So the order in std::map is temporary stable, but not for long. I have changed map to unordered_map, thus exposing the problem.
I propose to fix this by blocking PropertyContainer::onChange() call temporary while undo/redo, i.e. inside TransactionObject::applyChn(). Once all changes are applied for the current transaction, call Property::touch() for each changed property. Any thoughts?
See this PR for the proposed fix. Class TransactionGuard is used to temporary disable onChanged() notification, and call touch() when goes out of scope.
This fix exposes another potential problem in PartFeature::onChange(Placement), as it modifies the Shape without recording it in the transaction.
||There is some mistake in the TransactionGuard PR. Fixed by force push. Also split the Part Placement/Shape onChanged() problem into a separate commit.|
|2020-02-15 10:38||wmayer||New Issue|
|2020-02-20 21:03||Kunda1||Tag Attached: undo|
|2020-02-20 21:04||Kunda1||Target Version||=> 0.19|
|2020-02-23 11:12||wmayer||Note Added: 0014177|
|2020-02-23 11:13||wmayer||Note Edited: 0014177||View Revisions|
|2020-03-14 10:01||wmayer||Note Added: 0014227|
|2020-03-14 10:31||wmayer||Note Added: 0014228|
|2020-03-14 14:19||wmayer||Note Added: 0014229|
|2020-03-14 14:20||wmayer||Priority||high => normal|
|2020-03-14 14:20||wmayer||Severity||crash => major|
|2020-03-22 22:21||wmayer||Changeset attached||=> FreeCAD master 2b16d060|
|2020-03-22 22:21||realthunder||Note Added: 0014265|
|2020-03-22 22:21||realthunder||Assigned To||=> realthunder|
|2020-03-22 22:21||realthunder||Status||new => closed|
|2020-03-22 22:21||realthunder||Resolution||open => fixed|
|2020-03-23 14:36||wmayer||Note Added: 0014270|
|2020-03-23 14:36||wmayer||Status||closed => new|
|2020-03-23 14:36||wmayer||Resolution||fixed => reopened|
|2020-03-23 14:37||wmayer||Note Edited: 0014270||View Revisions|
|2020-03-23 16:08||wmayer||Note Added: 0014271|
|2020-03-24 03:18||realthunder||Note Added: 0014273|
|2020-03-24 09:34||realthunder||Note Added: 0014274|
|2020-03-25 00:50||realthunder||Note Added: 0014287|
|2020-10-17 10:26||Kunda1||Tag Attached: #pending-PR|