1
\$\begingroup\$

Within my Unity Project in my code, (see below), I have a button called Check which executes when CheckPress() function is called. I read two approaches by which this can be done.

Appraoch 1: Using Check.onClick.AddListener(CheckPress); and then attaching script to Canvas. When I press run and click the Check button, this works.

Approach 2: The other approach I read is that, I can attach my script to Canvas. From there I select the button Check from hierarchy, then under inspector I see On Click(), I click + sign and then drag the Canvas and place it in Object (see the attached image), then under No Function I select the CheckButtonBehaviour Script and select the CheckPress(). When I press run and click the Check button, this also works as intended.

I wanted to know if these two approaches are same or different. If they are different, then in which context either approach should be implemented.

using System.Collections.Generic;
using System.Collections;
using UnityEngine;
using UnityEngine.UI;
using System.IO;
using System.Threading;
using UnityEditor;
using System.Text;
using System.Net;
using System.Net.Sockets;
using System;
using System.Linq;


public class CheckButtonBehaviour : MonoBehaviour
{

public Button Check;
public Button Play;
public Button NextSignal;

public List<string> signals = new List<string> {"Speech1", "Speech2", "Speech3", "Speech4"};
public List<string> shuffledSignals = new List<string>();
public int index = 1;
public int counter = 3;


private static int localPort;
private string IP;  
public int port = 8050;
IPEndPoint remoteEndPoint;
UdpClient client;


void Start()
{
    
    var rndr = new System.Random();
    shuffledSignals = signals.OrderBy(i => rndr.Next()).ToList();

    IP = "127.0.0.1";
    port = 8050;
    remoteEndPoint = new IPEndPoint(IPAddress.Parse(IP), port);
    client = new UdpClient();
    Play.gameObject.SetActive(false);
    NextSignal.gameObject.SetActive(false);

    Check.onClick.AddListener(CheckPress);

}

public void CheckPress()    
{
    

    byte[] data0 = Encoding.ASCII.GetBytes("starting"); ///OLD CODE part
    client.Send(data0, data0.Length, remoteEndPoint);
    Debug.Log("<color=blue>Something is sent to MAX</color> : starting");

    Check.gameObject.SetActive(true);
    Check.interactable = false;
    Check.enabled = false;

    Play.gameObject.SetActive(true);
    NextSignal.gameObject.SetActive(true);

   
}
\$\endgroup\$

1 Answer 1

2
\$\begingroup\$

In this particular context there is no good reason to use one over the other.

But in general, there are a couple things you might want to consider:

  • Assigning buttons in the inspector requires no programming knowledge. So when you are working with a UI designer who can't program C#, then you just need to provide them with the methods the UI is supposed to call and they can do most of the work themselves.
  • When you do it via the inspector, then you can assign a click listener on a gameObject which does not even know the button exists. When you do it in code, then the script which sets up the click handler needs to know both the button and the object which implements the click handler. Usually it's not a problem to create that connection, but it might be additional boilerplate-code you need to write, and in the end you still end up drag&dropping one object into an inspector field of another, just like you would do if you set up the button handler in the UI.
  • When you do it in code, then you can do more than just assign a method. You can, for example, assign a lambda expression. Which then has access to all the variables in the scope where it was defined. That allows you to do some elegant things. AddListener(()=>{ currentlySelectedUnit.attackTarget(enemies[i]); })
  • When you do it in code, then you can assign and reassign button listeners at runtime. This is useful when you have a situation where the object which is controlled by a given button isn't known until the game is running. Or where it changes over the course of the game. You could of course solve this with another layer of indirection: The button always calls the same method of the same object (some kind of "UI Manager" perhaps), and that object knows the current context in which that action should be performed. But when you do it in code, then you can skip that additional indirection layer.
\$\endgroup\$
1
  • \$\begingroup\$ Yes the main difference is WHO you expect to be hooking up the button. If you aphasie a large team with programmers and designers who don’t code much. The UI-based method makes sense. Since then both groups can make changes. If it’s just you, it comes down to personal preference. \$\endgroup\$
    – Adam B
    Commented Nov 19, 2020 at 15:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .