Skip to main content

HookViewToolkit Component

HookViewToolkit is the UI Toolkit equivalent of HookView. Reach for it when your screen is built with UXML/USS and a UIDocument instead of a Canvas.

It's [RequireComponent(typeof(UIDocument))] and implements the same IHookView interface as HookView. That means HookUIManager treats a HookViewToolkit exactly like a HookView for navigation purposes — same Category/ID system, same registration via HookUIManager.RegisterView / UnregisterView in Awake/OnDestroy, same OnStartBehavior, and the same Show() / Hide() / ImmediateShow() / ImmediateHide() / OnShowStarted / OnShowFinished / OnHideStarted / OnHideFinished surface.

Inspector Properties​

Identity​

  • Category: Grouping for this view (e.g., "General", "HUD").
  • ID: Unique identifier string.

Behavior​

  • On Start Behavior: same enum as HookView — DoNothing, InstantHide, InstantShow, ShowAnimation, HideAnimation.

Events​

  • OnShowStarted, OnShowFinished, OnHideStarted, OnHideFinished — standard UnityEvents, fired at the same points in the lifecycle as HookView.

Unlike HookView, there's no State Management section — HookViewToolkit has no DisableGameObject/DisableCanvas/DisableGraphicRaycaster/HandleCanvasGroup toggles. It doesn't use a CanvasGroup at all; visibility is controlled entirely through the UIDocument's root VisualElement.

How visibility works​

Instead of toggling a CanvasGroup, HookViewToolkit sets DisplayStyle on its root visual element:

  • Show sets rootVisualElement.style.display = DisplayStyle.Flex.
  • Hide sets it to DisplayStyle.None.

It also explicitly manages pickingMode on the UIDocument's root visual element (Position when visible, Ignore when hidden). This matters because a UIDocument's implicit panel root can still intercept pointer events over its full-screen area even when its visible content is hidden — which would otherwise silently block Canvas/uGUI input elsewhere in the scene.

Animation model​

HookViewToolkit does not use HookAnimatorComponent. Its Show()/Hide() instead add/remove USS classes and wait out a fixed duration:

  • ShowRoutine() adds the animate-show class to the root element (and to any child with the animate-element class), waits GetAnimationDuration() seconds (currently a hardcoded 0.3f), then removes the class.
  • HideRoutine() does the same with animate-hide, then sets DisplayStyle.None.

Drive the actual transition visuals yourself via USS transitions keyed off .animate-show / .animate-hide. ImmediateShow()/ImmediateHide() skip the animation classes entirely and just flip the display style.

Auto-binding buttons and inputs​

On Start(), HookViewToolkit scans its UIDocument tree and auto-binds elements by name convention — there's no HookButton equivalent required inside a HookViewToolkit screen:

  • btn_nav_{ViewID} — clicking triggers navigation to {ViewID} (routed through HookUIManager.OnButtonPressed($"nav_{ViewID}")).
  • btn_action_{ActionName} — clicking fires a generic action (routed through HookUIManager.OnButtonPressed($"action_{ActionName}")).
  • Any other named Button — registered as-is with HookUIManager.OnButtonPressed(buttonName).
  • input_{Name} — any TextField with this prefix gets a RegisterValueChangedCallback wired up (value handling/storage beyond logging is left as a TODO in the current implementation).

Bindings are torn down in OnDestroy().

Other utility methods​

public VisualElement GetElement(string name);

public void TriggerTransition(string elementName, string classToAdd, string classToRemove = null);

GetElement looks up a child element by name for runtime manipulation. TriggerTransition adds/removes USS classes on a named element — a quick way to drive one-off transitions without writing a full show/hide routine.

Authoring​

Unlike HookView, there's currently no clone-based Editor authoring helper for HookViewToolkit (the way HookUIScreenBuilder.CloneScreen clones an existing HookView prefab). You author the UXML/USS by hand and attach HookViewToolkit to the GameObject holding the root UIDocument.