UIInput gameobjects do not receive OnKey event

[indiefreaks]

Hi,

I noticed that UIInput gameobjects don't receive OnKey events when the focus is set on them preventing us from using ButtonKeyBindings to create forms which support keyboard tab and shift-tab navigation.

I wondered if there was a specific reason for this?

Until I get your response, I commented out the inputHasFocus boolean test in UICamera.Update() method which fires or not the ProcessOthers() method in which the OnKey event is raised by your system. ('til now, it doesn't seem to have any side effect).

Thanks

[ArenMook]

You should be using UIButtonKeys script for that, not UIButtonKeyBindings. Key binding scripts is for pressing a UI button with a keyboard key. Tabbing / controller navigation is done via UIButtonKeys. There is an NGUI example on that.

[indiefreaks]

I'm sorry, I actually typed it wrong: I did meant to say Button Keys and not Button Key Bindings.

When a UIInput is placed on a gameobject, no other attached script will receive the OnKey event because of this test you make on the UICamera.Update() method that I mentionned in my previous post.

You can verify it by yourself adding a Button Keys script to an Input gameobject or even simpler adding a custom MonoBehaviour class with a simple Debug.Log() call in a void OnKey(KeyCode key) method implementation.

I removed the test for the inputHasFocus boolean set in the code above the ProcessOthers() method call and it still run fine. What was the purpose of such test?

Thanks

[ArenMook]

This test is necessary because you don't want to activate key bindings while chatting.

[indiefreaks]

So maybe the UIInput isn't actually generic enough. UIInput could be use for simple username and password fields in a form thus requiring Button Key Bindings (for standard keyboard navigation functionnality) or for a chat input too.

What would you recommend? Should I create my own textbox specific UIInput scripts to handle form "like" behaviors and use NGUI's UIInput script for other more text intensive inputs?
Or would you consider specializing these scripts in the future to handle both scenarions therefore mimicing the Windows controls differentiation between a "Textbox" and a "TextArea"?

Thanks

[ArenMook]

Hmm... looking some more into this, there is a check for inputHasFocus inside the ProcessOthers function already, so the check you pointed out is indeed not necessary. Removing it doesn't seem to have any adverse effects. I'll fix it locally and you will see it in the next version.

1. // Update the keyboard and joystick events
2. if (mSel != null) ProcessOthers();

[indiefreaks]

Great! I'm pleased to see that it made it through

Btw, these are the best 100€ I spent on the store so far: great job with it