Search Unity

Solved:new UI system

Discussion in 'UGUI & TextMesh Pro' started by kelvinwop, Jan 30, 2015.

  1. kelvinwop

    kelvinwop

    Joined:
    Dec 15, 2014
    Posts:
    36
    how do you reference a button as a variable?

    Code (CSharp):
    1. public UnityEngine.UI.Button leftbutton;
    doesn't appear to show up in the inspector.
     
  2. User340

    User340

    Joined:
    Feb 28, 2007
    Posts:
    3,001
    Does it compile?
     
  3. SimonDarksideJ

    SimonDarksideJ

    Joined:
    Jul 3, 2012
    Posts:
    1,689
    Tried it and the above works for me.
    upload_2015-1-30_7-39-39.png
    However (personally) I would just use a standard GO and then manage a reference internally to the Button Component.
    Allows you to verify it is a button and also access anything else on the GO if need be.
     
  4. User340

    User340

    Joined:
    Feb 28, 2007
    Posts:
    3,001
    What? How does it allow you to verify it's a button? If a Button component is dragged in the inspector how is that not verified? How can one not access anything on the gameobject with Button?
    Code (csharp):
    1. Button.GetComponent<Rigidbody2D>().transform.position = Vector3.up * 0xABCDEF;
     
  5. SimonDarksideJ

    SimonDarksideJ

    Joined:
    Jul 3, 2012
    Posts:
    1,689
    It's just semantics @_Daniel_ , as they all derive from MonoBehaviour, the behaviour to put above would work regardless.

    It all depends on your use case, if it HAS to be a button, then having a property of Button is fine.
    If you intend to use it for other things (not just a button) then make it a generic GO. (it's stored internally as a GO anyway)

    In either case, if you want to use the Button component in code, you will still have to do Button.GetComponent<Button>.
    Having it as a property of button just helps the editor validate what you attach to it.

    Point of debate really, it is just my preference.
     
  6. iivo_k

    iivo_k

    Joined:
    Jan 28, 2013
    Posts:
    314
    Not true. If it's a Button, it's a Button.
     
    User340 likes this.
  7. SimonDarksideJ

    SimonDarksideJ

    Joined:
    Jul 3, 2012
    Posts:
    1,689
    And if it's a control that derives from the Button class, it's still a button :D
     
  8. iivo_k

    iivo_k

    Joined:
    Jan 28, 2013
    Posts:
    314
    Point is, you don't have to do button.GetComponent<Button>(), if you have a serialized Button field in the inspector.
     
  9. SimonDarksideJ

    SimonDarksideJ

    Joined:
    Jul 3, 2012
    Posts:
    1,689
  10. kelvinwop

    kelvinwop

    Joined:
    Dec 15, 2014
    Posts:
    36
    solved: I just needed stuff in the void Start() block. Apparently those public variables don't show up without stuff in there or something. I don't know, so correct me if I'm wrong.
     
  11. Velo222

    Velo222

    Joined:
    Apr 29, 2012
    Posts:
    1,437
    Last time I tried to drag a button over a public variable in the inspector it didn't work. Both when I tried using the "GameObject" type and the "Button" type itself. Does it work now somehow?
     
  12. LunaticEdit

    LunaticEdit

    Joined:
    May 1, 2014
    Posts:
    60
    It should work. Make sure it's a public class member, and also make sure you don't make it a property by adding { get; set; } after it. For some reason, unity disregards these. an example would be:
    Code (CSharp):
    1. using UnityEngine;
    2. using UnityEngine.UI;
    3.  
    4. public class MyGameObject : MonoBehavior
    5. {
    6.     public Button Mybutton = null;
    7. }
    You should now be able to drag over any GameObject that contains a Button component onto it. Do note it may take Unity's IDE a moment to add the property. If you look in the bottom right of the screen you'll see the little "spinner" while it's compiling changes. Sometimes on larger projects it could take 15 seconds or more to finish.

    I wouldn't recommend just generically using the GameObject type if you explicitly require a Button component. This will make your script inspector properties a ton harder to maintain and understand.
     
  13. Velo222

    Velo222

    Joined:
    Apr 29, 2012
    Posts:
    1,437
    Ok thanks LunaticEdit. I will have to try it again then. That will make it a lot easier if it works :)