Undo and redo are sometimes problematic.

[Julie_7]

In my previous post https://forums.autodesk.com/t5/fusion-360-design-validate/why-does-changing-sketch-plane-move-sketch... I was trying to explain the problem. Because I did not know that I was going to report a problem I was not creating screen captures during the process. My solution was to just use undo to get back to the condition where I started to capture the initial condition.

I wanted to show the origin in the screen capture so I click on show and captured the initial condition for my post. Then I went to redo so that I could move forward with the steps that I had taken. I found out that there was no longer a redo stack.

The problem is that the undo/redo stack includes all actions and not just model actions. Showing the origin was a new entry in the stack and removed all my work after the point that I had rolled back to.

I have always been surprised that undo included actions like changing visibility and dragging the workspace. They are not changes to the design.

The timeline would normally be what I would use to roll backwards and forwards with the design to show what I have done, but sketch actions are not captured in the timeline. Nor are edits of features, or changing sketch planes. This leaves the undo stack as the only way to see all changes that are not captured in the timeline.

In this case it was easy to recreate the lost work.

I am left wondering about the two different timelines and how they work or should work.

The timeline shows the order of feature creation and in some cases makes reorganizing a design hard because some operations are captured and some are not. I can often reorder features or delete them. In contrast, some operations such as deleting a component (I think this is one of the captured operations) gets inserted into the timeline at the end.

The normal undo/redo stack "timeline" is very useful and captures actions that do not show up in the timeline, such as editing a feature. It also captures actions taken on the timeline such as changing the current position. In addition it captures every view change or movement. This can be useful to see all the details of what has just been changed and undo at a very granular level. Sadly, the interaction of view changes and design changes in the stack can lead to the issue of undoing to see something, but needing to change the "view" to really examine the prior state discards all the work that needs to be kept. I cannot use the undo stack to review a set of actions. I can use the timeline to review a set of actions.

I do not have a solution to this. I just know that I was not thinking about how the undo stack worked at the time and I lost quite a bit of work. I guess that having view only changes when the stack is not at the end not delete the redo stack having redo work on the undone part of the stack ignoring the view changes could be a solution. Maybe just notifying the user when a view action is going to delete the redo stack so they can decide if they really want to discard all the "real" work just to change the view.

[jeff_strater]

"I have always been surprised that undo included actions like changing visibility and dragging the workspace. They are not changes to the design."

I'm not sure what you mean by "dragging the workspace", but visibility is most definitely a change to the design.  If you make a Body invisible and save it, would you not expect for that Body to be invisible if you close down Fusion and re-open it?  Basically, any change to the design that needs to be persisted is a transaction, and therefore is undoable.  Things that are not transactions include:  Changing the view (zoom, pan, rotate), changing the UI (adding/removing tools from the tool bar - those ARE saved, but not saved with the design, so are not transacted).

[Julie_7]

Dragging the workspace is moving the position of the visible items. The view cube changes the angle of the view, and dragging the workspace "moves" the view.

Just because visibility is saved with the design, does not imply it is a change of the design. I would not expect changing the visibility of a body to have any affects on the calculations performed when recomputing the design. (Of course, I also do not think visibility should prevent exporting a body in the API to prevent it from being exported when the body is not visible, but it does.)

The bottom line is that there is a strange dichotomy of actions, some that get put in the undo stack and some that get put in the timeline. Now you have added another dimension for me to ponder - action saved in the design vs. those that are not saved.

I actually understand why a sketch is saved as a unit and not as individual actions in the timeline. The timeline holds things that get computed. Individual lines in a sketch are just lines.

I always get something out of your replies Jeff. Thank you!

The easy answer to everything is "it is complicated".
🙂