-Problem
If you dont implement CreateInspectorGUI(), while the inspector is still drawn, your custom PropertyAttribute’s will get broken.
If I’d try to explain what I did:
I created a PropertyDrawer for a PropertyAttribute, it was working if it wasnt used in a custom editor.
Project does not uses IMGUI for Editor (set in ProjectSettings>Editor>UseIMGUI)
Yes, i already implemented what they told.
Using [CustomPropertyDrawer(xx, true)] not works
Later on, i found the issue. I had an CustomEditor for the MonoBehaviour. When i disabled the custom editor, the attributes was working fine. But when i open the custom editor, it was breaking the custom attributes.
So an empty CreateInspectorGUI() in your CustomEditor will break your custom property fields even tho your internal-fields are drawn in the Inspector. It will show an error of No Gui Implemented for every custom PropertyDrawer you created.
To resolve this, i didnt rely on internal methods and used InspectorElement.FillDefaultElement() for every custom editor i created:
using UnityEditor;
using UnityEditor.UIElements;
using UnityEngine.UIElements;
[CustomEditor(typeof(XXX))]
public sealed class XXXEditor: Editor
{
public override VisualElement CreateInspectorGUI()
{
var rootElement = new VisualElement();
InspectorElement.FillDefaultInspector(rootElement, serializedObject, this);
return rootElement;
// return null;
}
}
This is not surprising. A custom editor overrides how a type is drawn, and this generally bypasses property drawers unless you specifically use a PropertyField.
And DrawDefaultInspector is IMGUI, and you can’t draw UI Toolkit inside of IMGUI, so any UI toolkit Property Drawers will not work in that context. That’s not going to change.
Yes, that is what i tried to show in the topic. In the current implementation, if OnInspectorGUI() or CreateInspectorGUI() is empty, it uses DrawDefaultInspector() which is using IMGUI that breaks the UITK PropertyDrawer’s.
Well, who will know? In the future, this topic could get more attention since UITK is slowly taking over IMGUI. Will they want thoughts like “oh their default implementation does not even support their own packages”? Depends on how much they hate their users.
This thing can get solved by multiple paths. Detecting whether inspector type drawer uses or using a simple if-else that checks project settings prefered inspector system inside that method. Or literally if drawer used both, select desired inspector system. Obviously there are more problems that can occur but i am not the engineer of the package at this point.
Right but if someone has written a custom inspector in IMGUI, and has some property drawers in UI Toolkit, no settings are going to get around that innate limitation. IMGUI can be drawn inside of UI Toolkit, but not the other way around. That’s not going to change.
Default inspectors (types with no custom editor) should be using UI Toolkit in more recent Unity versions, unless the option to use IMGUI inspectors has been checked. If that’s not happening, that would be a bug (though addons like Odin Inspector may override this behaviour).
Upon reflection, I can imagine a situation where you implement a custom editor without any inspector stuff, namely to use OnSceneGUI or similar for example. I feel like that resulting in an unintentional forced IMGUI inspector is probably an unwanted or unexpected side effect. Though there are more modern API’s like the Overlay API that could be used in lieu of that.
If you want to draw the default UI Toolkit inspector you can use an InspectorElement.
There’s a couple of ways to use it but I tend to do this:
public override VisualElement CreateInspectorGUI() {
VisualElement root = new();
InspectorElement.FillDefaultInspector(root, serializedObject, this);
// Can add extra elements to root here.
return root;
}