Search Unity

Purpose of UIBehaviour

Discussion in 'Unity UI (uGUI) & TextMesh Pro' started by casimps1, Jan 7, 2015.

  1. casimps1

    casimps1

    Joined:
    Jul 28, 2012
    Posts:
    253
    Doesn't seem to be a lot of info on the new UIBehaviour class...

    I know from the limited documentation and looking at the UI source code that UIBehaviour is pretty much just MonoBehaviour with some of the Unity lifecycle functions (Awake, Start, OnDestroy, etc.) declared as empty protected virtual methods. I also know that most (all?) of the new UI classes (Image, Button, Selectable, etc.) derive from UIBehaviour.

    I just don't understand why and when I should be using it as well. I tried creating a custom UI OnPointerDown event handler for one of my buttons and it seems to work fine when derived from MonoBehaviour instead of UIBehaviour.

    Anybody know?
     
  2. v01pe_

    v01pe_

    Joined:
    Mar 25, 2015
    Posts:
    49
    Was curious as well… this is where my research lead me first :)
     
  3. Hosnkobf

    Hosnkobf

    Joined:
    Aug 23, 2016
    Posts:
    692
    I also looked into the reverse engineered code and searched for references.
    Looks like this behavior is really a bit useless.
    My best guess is that Unity Developer just wanted to write proper C# code without these magic function calls where you need to know the function name.
    Maybe there is also a performance reason to have such a base class (the magic code doesn't have to check if the method exists... maybe there is somewhere a collection of UIBehaviours in the native part of unity).

    Hope a Unity developer reads this and brings some light into the darkness :)
     
    bguild, wangzj89 and levlaj like this.
  4. a436t4ataf

    a436t4ataf

    Joined:
    May 19, 2013
    Posts:
    230
    Note to help anyone who hit the problem I just had:

    The UIBehaviour callbacks will NOT run in the Editor, even though this is the most obvious place they're useful/needed (writing custom UI components, UI layouts -- you need to make sure your UI looks the same in editor as it does in the game!).

    You need to add ExecuteAlways/ExecuteInEditMode to every single one of your UIBehaviour scripts or nothing will work :). Seems pretty dumb that UIBehaviour doesn't automatically provide this.
     
  5. karsnen

    karsnen

    Joined:
    Feb 9, 2014
    Posts:
    65
    My research led me here.
     
  6. Salveiro

    Salveiro

    Joined:
    Jul 24, 2018
    Posts:
    1
    I've asked myself the exact same question. Why this weird case is not better documented? :) Just one more redundant layer of abstraction
     
  7. guneyozsan

    guneyozsan

    Joined:
    Feb 1, 2012
    Posts:
    63
    My guess is they wanted enforce inheritance of Unity lifecycle functions. For example, if Button is like
    class Button { private void Awake {...} }
    you could easily override Awake without knowing by writing
    class MyButton: Button { private void Awake {...} }
    . But when they are empty protected you have to do
    class MyButton: Button { protected override void Awake { base.Awake(); // probably ...} }
    , this way you get a compiler warning if you override a UI element lifecycle functionality by mistake.

    I think this should be default for all Monobehaviors. Sometimes you override one Awake or Start without knowing then it becomes very hard to find what's going on.