Скачать или смотреть Resolving the Unity EditorWindow OnGUI Data Loss Issue for List string[] Types

Learn how to properly manage data persistence in Unity EditorWindows with a workaround for `List string[] ` that prevents data loss on recompilation.
---
This video is based on the question https://stackoverflow.com/q/73311239/ asked by the user 'P-ratt' ( https://stackoverflow.com/u/4122230/ ) and on the answer https://stackoverflow.com/a/73311868/ provided by the user 'hijinxbassist' ( https://stackoverflow.com/u/1679220/ ) at 'Stack Overflow' website. Thanks to these great users and Stackexchange community for their contributions.

Visit these links for original content and any more details, such as alternate solutions, latest updates/developments on topic, comments, revision history etc. For example, the original title of the Question was: Unity EditorWindow OnGUI doesn't save data for List string[] types

Also, Content (except music) licensed under CC BY-SA https://meta.stackexchange.com/help/l...
The original Question post is licensed under the 'CC BY-SA 4.0' ( https://creativecommons.org/licenses/... ) license, and the original Answer post is licensed under the 'CC BY-SA 4.0' ( https://creativecommons.org/licenses/... ) license.

If anything seems off to you, please feel free to write me at vlogize [AT] gmail [DOT] com.
---
Understanding the Problem: Data Loss in Unity EditorWindows

As a game developer using Unity, you may encounter issues when working with custom EditorWindows, especially with data persistence. One common problem arises when using List<string[]> in your EditorWindow. You might notice that although your data appears to be added correctly to the list, it disappears entirely when Unity recompiles the scripts. This problem can be particularly frustrating as it interrupts your workflow and hampers productivity.

In the given example below, we have a simple EditorWindow class that adds labels based on the number of elements in a List<string[]>. The behavior observed indicates that when you add a new entry to the list and then simply save or modify any script, the entire contents of the list vanish:

[[See Video to Reveal this Text or Code Snippet]]

The Root Cause of the Issue

The reason behind this data loss is that Unity does not support the serialization of multidimensional collections directly, such as List<string[]>. When Unity recompiles scripts, it fails to save the contents of the list, resulting in the loss of any previously added entries.

Let's explore how to overcome this limitation.

The Solution: Implementing a Workaround

Fortunately, there's a straightforward workaround to manage this situation effectively. The key is to create a dedicated class to hold the string arrays. By doing this, you can utilize a list of that class instead of directly using List<string[]>. This allows Unity to serialize the data correctly and maintain its state even after recompilation.

Step-by-Step Implementation

Create a Serializable Class: Define a new class that will encapsulate the string array. This class must be marked with the [System.Serializable] attribute.

[[See Video to Reveal this Text or Code Snippet]]

Modify the Original List: Change the type of myList from List<string[]> to List<StringArray>

[[See Video to Reveal this Text or Code Snippet]]

Update the GUI Logic: When adding new entries in your OnGUI method, you will now instantiate the StringArray class and add it to your list.

Final Code

Here's how your modified EditorWindow class would look after applying the changes:

[[See Video to Reveal this Text or Code Snippet]]

Conclusion

By encapsulating your string arrays within a serializable class, you can effectively resolve the issue of data loss in List<string[]> when using Unity's EditorWindow. This not only ensures that your data persists across recompilations but also enhances the overall reliability of your custom editor tools.

If you ever find yourself facing similar challenges in Unity, remember that often the solution lies in how the data structures you use are defined and managed. Happy coding!