MarkupBinding

Remarks

Doc 36 § P4, and it is Unity's arrangement exactly. A custom inspector clones a tree and returns it; binding happens after the method returns, by walking what was built and wiring each element that named a member. The markup does not know about the C# and the C# does not know about the markup — the two are joined by name, which is the whole reason a .vxml inspector needs no code-behind.

⚠ Two ways to name a member, because they answer different questions. <PropertyField Path="Speed" /> says "draw this the way you would have"; <Slider binding-path="Speed" /> says "I have chosen the control, join it up". An inspector that only had the first could not lay anything out; one that only had the second would make every author reimplement the default row.

⚠ The walk stops at a nested PropertyField and nowhere else. A drawer builds its own elements inside the row, and some of them are the very controls this binds — a second pass over them would join a colour well's red channel to whatever member the enclosing field named.

Methods (1)

• public static int Bind(UiElement root, EditTarget target, DrawerRegistry? drawers = null)

  Joins every element under a root that named a member.

Used by (6)

• BrushInspectorMarkupTestsVixen.Editor.Terrain.Tests
• FrameInspectorMarkupTestsVixen.Editor.AssetEditors.Tests
• MarkupBindingTestsVixen.Editor.Inspector.Tests
• MarkupInspectorVixen.Editor.Inspector
• NodePortProviderTestsVixen.Editor.NodeGraph.Tests
• PanelTestsVixen.Editor.Inspector.Tests