I’m developing a tool to display notes in Unity, which has an editing window. During development, I found that the TextField does not support undoing text modifications.
When editing long text and making a mistake, trying to press Ctrl Z to undo is a very natural reaction, but in Unity, the content in the TextField is not undone, and worse, this undo operation actually undoes some previous modification to an asset, which the user may not even notice.
Additionally, some people use Unity to develop non-game applications, and the inability to undo text editing in TextFields will severely undermine Unity’s capabilities for practical software development.
Is this text field correctly bound to a serialised property? All Undo in Unity is done at the asset level, and it handle automatically is working through the SerializedObject/Property system. A TextField in a vacuum can’t really handle undo without an asset to record the undo via.
It is not bound to the SerializedProperty. I will implement the undo functionality in this way next, but this approach cannot solve the runtime undo problem.
In my tool, the data does not have very deep nesting levels, so wrapping it with SerializedProperty is relatively simple. But if the data has very deep nesting levels, it would become quite troublesome.
I mean if there was to be runtime Undo support, it should be implemented across all fields and not just the text field.
In any case, for an editor tool you should be using the serialized property binding system as much as you can as this will save you a lot of the work for dirtying the asset, undo support, and prefab modification support as well. It’s there to do a lot of the work for you.
If the data behind the UI belongs to an asset, I would prioritize using SerializedProperty. However, in many cases I need to deal with data that is not part of the UnityEngine.Object hierarchy, and in those situations using SerializedProperty would require creating a temporary ScriptableObject wrapper class, which is an undesirable workaround.
I feel it would be better if Unity itself provided built-in support for handling this type of data.
The UI is only a view of your data and cannot generally handle undo. Undo needs to be handled in your data to ensure consistency and then the UI is updated accordingly.
As Spiney pointed out, when working with serialized data, using the SerializedObject binding system lets Unity handle Undo on the level of the data and the binding will update your UI.
In case you’re using your own data structures, you need to handle Undo yourself. You can use the Undo class to interact with Unity’s undo system but you still need to have Unity Objects and some serialized data for Unity to track.
why’d you want undo support for runtime tho?
You can make your own undo stack for this, I’ve done this in the past for input fields but NOT for runtime (edit-mode) and rely on the undo/redo signal in the editor.
