These methods do this: when i create a button, i initialize that and i give the class Object that contains all the info that the button needs. When i initialize the button objClass is not null (i can see it with Debug.Log()), but when i watch the variable on the inspector or i call a method like OnClickProposeExchange() the variable is null and i don’t understand why.
public void InitializeButton(bool isAnObjectButton, byte proprietor, Object objCharacts)
{
objClass = objCharacts;
Debug.Log("obj class: " + objClass); //the output is NOT null here
isObjButton = isAnObjectButton;
owner = proprietor;
Configure(); //here i don't use the value of objClass
if (isAnObjectButton) // consider this always true
{
if (owner != 0) // consider this always true
{
pnlToOpen.transform.Find("btnProposeExchange").GetComponent<Button>().onClick.AddListener(OnClickProposeExchange);
}
}
}
void OnClickProposeExchange() // when i click this button
{
Debug.Log("On click propose exchange: classe:" + objClass); //now the output is null
marketManager.OnCreatingExchange(objClass, owner); // and he gives me an error
}
Could you show the declaration of the variable? What’s its type, privacy, scope?
In Visual Studio, you can right-click a variable and say “find all references” to get a list of all code using that variable. This can be a helpful way to try to find something that you forgot was modifying it.
Even if every script sets itself as a listener, it might be difficult to correlate the Debug.Log on line 5 and the Debug.Log on line 25 to tell which ones are coming from the same script and which ones are coming from different scripts.
Wait, you declared your own class named Object? That’s very confusing.
Does it inherit (directly or indirectly) from MonoBehavior? A MonoBehaviour variable will compare as “equal” to null if gets destroyed, even if it’s not literally null.
Destroyed monobehaviours also give an error when you try to dereference them (although I think the error is worded differently compared to if they were truly null).
I’m pretty sure that only when you try to get at “Unity-ish” parts of them, such as .transform or .gameObject, or any of the in-built methods will it actually throw an error.
As far as your own instance fields, properties and functions in a Destroy()ed MB, hey, go nuts. They’re all still there until eligible for GC. It’s not GREAT practice, but nothing stops you from keeping a list of historically-used MBs once they’re destroyed, although I imagine you really have no way of knowing how much other referenced stuff is being kept from GC by that one reference!!