koobas.hobune.stream
How to prevent EditorGUI.indent from overriding property height (only)
I have a simple property drawer, which draws a single object field, for a Texture object. Both the ObjectField height, and the property height, used by this custom property drawer, are static. Here are the relevant property drawer lines, from inside OnGUI. (Will post full custom property drawer upon request- its nothing special though) …
position.width = 80;
position.height = 80;
Texture2D temp_tex = (Texture2D) EditorGUI.ObjectField(position, GUIContent.none, tex, typeof(Texture2D), false);
…
public override float GetPropertyHeight(SerializedProperty property, GUIContent label)
{
return 100f;
}
However, when I adjust the indent level, before drawing the property, it appears to affect the HIEGHT of the drawn ObjectField. But I expected "indent" to only affect the width, and x position of the position Rect.
public override void OnInspectorGUI()
{
EditorGUILayout.PropertyField(serializedObject.FindProperty("tester"));
Rect position = EditorGUILayout.GetControlRect(true, 100);
EditorGUI.indentLevel++;
EditorGUI.PropertyField(position, serializedObject.FindProperty("tester"));
EditorGUI.indentLevel--;
}
Yields: 
Note that the drawn height of the two ObjectFields, is different. The one that is drawn after increasing the indent, is displayed smaller than the 80 pixels hard-coded (let me repeat that in bold: hard-coded) in the property drawer.
How do I prevent adjustments to the indent level, from affecting height? (but still affect horizontal position, as normal) Do I actually need to reset the Indent Level to zero, apply my own changes to the rect width and x position, then change it back (possible, but a huge pain, and conflicts with advice on bottom of EditorGUI.indentLevel docs page)?
Setting the EditorGUIUtility.hierarchyMode flag to false, didn’t help : http://answers.unity3d.com/questions/1320999/editorguifoldout-docs-wrong.html
For the sake of posterity, I wanted to share what I sent back from the bug report:
Thanks for submitting! Now that I can see all of your code in context, I can confirm this is not in fact a Unity bug.
The problem is that when you use the various EditorGUI methods, they will respect the current indent level within the rect where you draw them. What happens is that your indent level inside of your ObjectField rect (the one with the large preview swatch) is still 1 at the time it is drawn, and Unity draws the swatch shorter so that it maintains the correct aspect ratio. So in this case, it is actually correct to manually set the indent level to 0 before you draw your ObjectField, and then reset it afterward.
Thanks for the update Adam. So, even though the EditorGUI-indentLevel documentation page specifically states that I should NOT compute my own indent, you are saying that IS what I need to do? Does unity provide the number of pixels per indent level, or should I hard code it?
"Unity draws the swatch shorter so that it maintains the correct aspect ratio." Oh, good to know.
$$anonymous$$ore generally, how do I know when a control is going to use the RECT I provide, and when it is going to change that rect, (and how the rect will be changed e.g. just Rect.x$$anonymous$$in, or height also)?
Just venting frustration: This kinda unexpected/undocumented behavior/apparent-inconsistency is making it very difficult to get my property drawers laid out right (not my first issue with this stuff)- screens that should take few hours seems to always end up taking days. ( here is another example http://answers.unity3d.com/questions/1320999/editorguifoldout-docs-wrong.html) If the layout behavior was properly documented, I wouldn't have a leg to stand on here, but this stuff is NOT documented: discovering undocumented behaviors like this is VERY FRUSTRATING. It leads to hours of doubting myself, testing, researching, and preparing a question for Unity Answers, and possibly submitting bugs (which wastes YOUR time too). (I know docs is NOT your department Adam, but if you could pass on my concerns/frustrations, to someone who CAN make a difference there, It would really be appreciated.)
I'm assu$$anonymous$$g you're referring to this part of the the EditorGUI.indentLevel documentation:
To maximize future compatibility, do not make assumptions about what a specific indent level means, but ins$$anonymous$$d just increase or decrease by one around blocks of controls that need to be more indented, as in the example above.
What this text means is that if you need to indent something, do it by changing this property rather than manually adjusting pixels on the rect that you supply to an EditorGUI call.
That said, it sounds like there are sort of 3 key pieces of information that you couldn't find (below). If you have specific suggestions of some obvious place or places this information should have been more explicit, I'd be happy to pass it along.
You should then expect that any control that is drawn via an EditorGUI (or EditorGUILayout) method will having indenting applied based on the current
indentLevel. The idea is that EditorGUI methods are still using your rect, they are just indenting the control within that rect. The ObjectField large preview swatch just has the peculiarity that it maintains a 1:1 aspect ratio, so the indentation ends up also affecting the height in the case that you have no label (i.e. are using GUIContent.none for the label).$$anonymous$$ost EditorGUI methods draw a row that consists of a label and a corresponding control, and are intended to be draw row-by-row. When there is a label present, the label is indented but the controls will all align along the same horizontal position. Where there is no label (i.e. you use GUIContent.none) then the control will span the entire indented rect. (There are some specific controls without labels, like reorderable list and serializable events, that currently do not respect indent level, but those should be considered bugs.)
When you are using something like a property drawer, you need to remember point number 1. There is some
indentLevelwhile your property is being drawn that may not be 0 (especially if your item is in an array or list), so if you are doing some kind of custom layout like yours, you must remember to adjustindentLevelwithin your PropertyDrawer's OnGUI() method accordingly.[1]: https://docs.unity3d.com/ScriptReference/EditorGUIUtility-fieldWidth.html
Thank you, Adam, those details are very useful!
"suggestions of some obvious place"
I would suggest the general aspects of number 1&2&3, should be somewhere under the EditorGUI Class page: Since it refers to the various EditorGUI member functions that take a RECT as a parameter, and the critical information needed is exactly how the RECT, IndentLevel (and any other factors) will be used/modified internally, to draw the control.
It might be worth it to create a "Rect Rules"(awful name, I know) subsection, kinda like the "Shader" area of the documentation does. I'd also suggest an exceptions sub-page that includes the aspect-ratio stuff for ObjectField, along with any others controls with exceptions to the Rect Rules laid out, like (perhaps?) Foldout.
A simple link to it this info, on each EditorGUI-taking-a-Rect-function page, and on the IndentLevel page, would help people find this info during a normal function "look-up" in the docs. Personally, I'm a fan of sample code and pictures.
Hi! This is a bug with how ObjectField works with Texture assets. Could you please file a report? It should be a super simple, 3-line fix, but I want to make sure we track it. If you post the case number I'd even be happy to take care of it Monday :)
That said, in the meantime, you're right this is the best workaround:
reset the Indent Level to zero, apply my own changes to the rect width and x position, then change it back
Thanks, Adam! I have submitted a bug report. Case number is: 945452 "take care of it $$anonymous$$onday" Woah, you mean like: fix the Unity Editor? Cool! So then it would be available whenever the next patch after that comes out?
Thanks for reporting. I see case 945452, which looks like yours.
If I can fix it $$anonymous$$onday, I make no guarantees how quickly it will get into a patch release, as it still has to go through some hoops to get into a release. For example, I can also see it looks like you're on 5.6.x, so it would have to make it into a newer version first before it is eligible for back porting. I can post here when I know for sure.
"back porting"?! ::sputters:: ... but ... oh .. ::clicks download:: Thanks again, Adam!
