Add Input.LeftMouseButton and Input.RightMouseButton constants

[User340]

I think it would be beneficial to have these constants. Now you have to always remember that Left mouse button = 0, etc. Usage:

if (Input.GetMouseButtonDown(Input.LeftMouseButton)) {
}

Easier to read too.

[Antistone]

I believe you could use PointerEventData.InputButton.Left for this if you wanted.

[Suddoha]

@_Daniel

I think it would be beneficial to have these constants. Now you have to always remember that Left mouse button = 0, etc. Usage:

if (Input.GetMouseButtonDown(Input.LeftMouseButton)) {
}

Easier to read too.

You could define them yourselfs.

However, I’m afraid that could cause some confusion, as it’s not correct from a technical point of view.

The documentation is a little bit inconsistent, in other words, it’s missing a tiny detail in some cases.

Documentation of Input.GetMouseButton

button values are 0 for left button, 1 for right button, 2 for the middle button.

Documentation of Input.GetMouseButtonDown

button values are 0 for the primary button (often the left button), 1 for secondary button, and 2 for the middle button.

Documetation of Input.GetMouseButtonUp

button values are 0 for left button, 1 for right button, 2 for the middle button.

Just noticed it’s differently documented everywhere.

Left and right are well-defined on a typical mouse, but the meaning of those indices is actually “primary” and “secondary” etc… , which can change. E.g. when you swap the buttons in your OS.

As an example, your code would then read “when the user clicks left …” even though it means “when the user clicks the primary button…” which can map to either left or right, depending on the settings.

So, in the end, it’s not actually a real problem, but the names of those constants would not necessarily match the hardware’s button.

[User340]

@Suddoha

You could define them yourselfs.

However, I’m afraid that could cause some confusion, as it’s not correct from a technical point of view.

The documentation is a little bit inconsistent, in other words, it’s missing a tiny detail in some cases.

Documentation of Input.GetMouseButton

Documentation of Input.GetMouseButtonDown

Documetation of Input.GetMouseButtonUp

Just noticed it’s differently documented everywhere.

Left and right are well-defined on a typical mouse, but the meaning of those indices is actually “primary” and “secondary” etc… , which can change. E.g. when you swap the buttons in your OS.

As an example, your code would then read “when the user clicks left …” even though it means “when the user clicks the primary button…” which can map to either left or right, depending on the settings.

So, in the end, it’s not actually a real problem, but the names of those constants would not necessarily match the hardware’s button.

Yeah but I believe that 99.99% of all mouses use left as primary.

@Antistone

I believe you could use PointerEventData.InputButton.Left for this if you wanted.

Are you sure? Did you test it? That would be great if you can verify.

[csofranz]

@_Daniel

Yeah but I believe that 99.99% of all mouses use left as primary.

That’s a bold statement,considering that 10% of all users are left-handed…

and:ALL mouses? You think Mickey’s a leftie too?

[palex-nx]

@csofranz

That’s a bold statement,considering that 10% of all users are left-handed…

Doesn’t OS handle that for us, developers? I think if mouse is in left-handed mode then button 0 will become right button and 1 left button. Left and right constant names of course won’t go, but Primary and Alternative buttons or something like that would be handy. I don’t like magic numbers to appear in code.

[Antistone]

@_Daniel

Are you sure? Did you test it? That would be great if you can verify.

If you’re the one who wants the test results, what’s stopping you from testing it yourself?

In any case, it’s an enum with a defined value of 0. If you cast it to an int, it will have the same effect as an integer value of 0. There’s not a whole lot that can go wrong here, other than the remote possibility that Unity could change it in a future version (and testing won’t help with that).

You will need to cast it, though.

[User340]

@Antistone

If you’re the one who wants the test results, what’s stopping you from testing it yourself?

In any case, it’s an enum with a defined value of 0. If you cast it to an int, it will have the same effect as an integer value of 0. There’s not a whole lot that can go wrong here, other than the remote possibility that Unity could change it in a future version (and testing won’t help with that).

You will need to cast it, though.

It works! Thanks again, great idea.