Using Input and Events in properties

Unity Engine
1

Does anyone know if Events and Input (GetAxis and GetButton) actually works in properties? I can’t seam to find the answer anywhere and it doesn’t seam to work either. Maybe I’m doing something wrong? Any help would be very appreciated. Here’s 2 exemples:

    public float LeftTriggerInputValue
    {
        get
        {
            if(Input.GetAxis("Oculus_CrossPlatform_PrimaryIndexTrigger") != 0)
            {
                OnLeftTriggerInput.Invoke();
                return Input.GetAxis("Oculus_CrossPlatform_PrimaryIndexTrigger");
            }
            else
            {
                return 0;
            }
        }
    }

    public bool JumpInput
    {
        get
        {
            if (Input.GetButton(jumpInputName))
            {
                OnJumpInput.Invoke();
                return true;
            }
            else
            {
                return false;
            }
        }
    }
2

first of all, i may just be being silly but why are you checking if it’s zero and then returning zero if it is zero…
(sorry but i had no clue how to structure that sentence)

would this not suffice, unless of course OnJumpInput.Invoke cant take zero, in which case i’m ranting about nothing?

OnLeftTriggerInput.Invoke()
return Input.GetAxis(“Oculus_CrossPlatform_PrimaryIndexTrigger”);

p.s. probably won’t fix the issue, but just try Input.GetAxisRaw() instead and see what happens?

3

Thanks for the reply! I figured out the issue, you can’t use Events in properties because they are called too often (way more than in Update) and it creates stacks overflow.

4

While you can technically do anything in a property than you can in a method, so therefore could call events and input.

It’s counter to the implied behaviour of a property.

Properties are methods that “look like” fields from a syntax context. As a result properties are things that you should be able to read/write frequently (for example a while loop that reads a prop will read it many many times).

Basically a method implies “work is done” where as a property implies “state is read/set”.
(firing an event is “work”)

This is why you discovered that its causing stack over flows because of the frequency of access. I’m assuming your event handler is then reading the property causing the event to go off again causing it to read it causing it to go off again causing you to read it… ad infinitum.

A good rule of thumb is a property should mainly just validate incoming values, or resolve outgoing values.

Example:

private float _positiveValue;
public float PositiveValue
{
    get { return _positiveValue; }
    set { _positiveValue = Mathf.Max(0f, value); }
}

This validates that the incoming value is >= 0.

public float Debit;
public float Credit;

public float NetTotal
{
    get { return Debit - Credit; }
}

Here NetTotal is resolving an outgoing value that isn’t actually directly stored, but rather is the difference of 2 other stored values.

…

This isn’t to say you can never have an event in a property.

A good example of one is say a “property changed” event:

public event EventHandler NamePropertyChanged;

private string _name;
public string Name
{
    get { return _name; }
    set
    {
        if(_name == value) return;
        _name = value;
        NamePropertyChanged?.Invoke(this, EventArgs.Empty);
    }
}

Note though that it’s done in the “set” event, and the event implies it would raise during the set. Which means if you set the Name property during the event handler it’s obvious you’re reraising the same event.

Where as in your original example… you’re doing it in the “get” event (which is weird… why would “getting” a value raise an event? I assume you were trying to do this so as to avoid having to read the value AND raise the event in place. In which case… create a “float ReadAndRaiseLeftTriggerInputValue()” method). There’s no reason for me to think looking at the name that the property would be doing this for any reasonable reason…

It’d be like if I set up my house to make coffee any time I looked at the clock. Why would I do that? Why would such a passive action do that? I don’t necessarily want coffee EVERY time I read the clock… it only just so happens I read the clock at 6am I am also making coffee. That’s incidental, they aren’t necessarily tied to one another.

1 Like
5

Awesome info! Thanks for taking the time to reply. This is all good to know!