koobas.hobune.stream
on windows player or standalone, numerical keys is a mess
-- EDIT
I was wrong, it behaves the same on mac and windows, I got confused because the "@" sign is on a different location on my mac than on my windows,
Hi,
As my app went into QA ( in my mind... :) ) , I just realized there is something very wrong with key inputs on Windows. Note that on mac everything is fine...
I have a gui Text field, when the user is entering text I keep getting the getKeyDown events in other scripts.
Input.GetKeyDown("3")
Why is the behavior different on windows and on Mac. It seems logical on mac that when the user is entering text in a gui text field key events are not dispatched. But I could settle if at least the behavior was consistent throughout platforms...
Now it gets worse...
if the user is using shift to input another character ( for example shift 2 is "@" on some keyboards) then I still get the getKeyDown events for "2" which is wrong, the user has really typed "@"...
I am missing a point? if the user wants to type "@", surely this is not "2" or is there a mix between the keyboard layout and the actual keys?
There is a mix up between the physical location of the character and the actual character ( don't know how to express it better.. sorry).
Do you have the same problems?!? I tested on two different windows machine ( both xp tho...) and it's consistent.
How do you then trap what the user has type properly? how to trap a physical key on one side and then how to trap the actual character the user has typed?
It's too bad I wanted to release today, everything else is perfectly working without a glitch.
Thanks for your help,
Jean
It's the same on mac too, and it's intended behaviour
Quick example - Imagine shift for run, 2 for swap to rifle in a combat game. You wouldn't want 2 to stop working when you press shift, and is probably true for most of the games out there in fact
Either way - if you want to test for @ instead of 2, try parsing Input.inputString instead, that'll give you the actual characters dependent on shift being held and the localization
Ok, I see, on my mac the @ sign is somewhere else on the keayboard hence I wrongly stated that it was behaving differently. and thanks for the redirection to Input.inputString, I know understand where I was wrong.
