[Bug 1.1 Alpha] Keyboard issue & Texteditctrl

#1 I Have the same issue.

No solution at the momment.

#2
Confirmed. The key event gets passed on to the text edit ctrl in focus when it should have been completely swallowed by the action map. Fixing this for the upcoming beta.

THREED-853.

#3 Okay, here's what's happening when the "Join" dialog is up and the player name textbox in focus:

1. The platform event code fires a keyboard down event into the system
2. The action map picks up the event and fires a toggleConsole command
3. toggleConsole pushes the console dialog onto the canvas
4. The player name textbox is losing focus and deactivates "keyboard translation" (the part of the event system that translates raw keypresses into character input events)
5. The console input textbox is gaining focus and enables keyboard translation
6. Control comes back up to the platform event handler
7. The event handler sees that keyboard translation is enabled and fires a character input event
8. The console input textbox receives the character input event and enters the character

The issue here is that there is no way for the platform event code to know if the raw keypress was handled somewhere or not. If it was handled, then it should probably not send a character input event. Unfortunately, this is a bigger change but I'm working on it.

//EDIT: corrected my mix-up of sleeping vs. in-focus

#4 Nice analysis.

Honnestly I tried to do it by myself multiple times without understanding how to fix that.

I'm pleased that you are taking care of this as it's seems not so obvious as it look :(

By the way on the join screen player name, the cursor is not set properly (1 character before the end). This might be nothing, but could also reflect a small bug!!

#5
Hehe, yeah, noticed that problem too. Fixed in HEAD. GuiTextEditCtrl wasn't placing the cursor properly when reading out its text from a script variable.

#6
Just noticed I was talking about waking up and going to sleep there. That's wrong. Keyboard translation is coupled to edit controls being in focus and not just being awake.

#7
This thing is really tricky. Haven't yet found a clean solution.

Torque's event handling stack is three-tiered. First comes the global action map, then the GUIs, and then the action map stack.

Character events are handled by first firing the event as a normal raw keyboard event into the system and then, if this is enabled, firing the event again as one or more translated character events.

However, this only works if the first event, the raw keyboard event, will not trigger any action in the system. In the current codebase, this is achieved by GUI code performing some logic of the kind "uh... oh... ok... *could* this be a character event... hmm... looks like it... just assume it is and pretend we have handled that event."

Ugly.

The proper way would be to either fire a raw keyboard event or one or more character events translated from the raw key info. However, deciding which is the correct thing to do for a given event has to happen in the platform layer and it is pretty non-obvious for the layer to decide as it depends on how the subsystems will react to either event.

So far, I've tried different approaches but none so far is good.

What this needs is

a) allowing journaled system events to return values [DONE]
b) building infrastructure to enable the platform layer to decide what to do with a keyboard event.

#8 It's a good thing that you are looking in fixing it as it seems to be far more complicated than we thought initially.

At the end, we will have a far more robust system for the keyboard input.

It's good that you explained what's the bug and how you are solving it, this is very interesting.

#9
Okay, fixed this in HEAD but due to the beta already being on its way to QA, this may not yet be included in it.

I have changed the event system so that keypress events are only fired as either raw keypress events or character input events. The latter only occurs if

• a) keyboard translation is active on the given window (activated if a text input ctrl has focus) and
• b) the window does not explicitly tell the platform layer to deliver a certain event as a raw keypress (which it does if the key is mapped in the global action map)

Fixing this for the PC side also revealed that dead-keys on Windows aren't handled correctly meaning that it's, for example, impossible to enter an é character into a text field when using a German keyboard layout. I'm looking into this.

#10 Thanks for this update. I hope you will find the dead key issue.

#11
Yep, definitely will fix this during the beta cycle.

Please note that due the fact that the event system changes outlined above had to stabilize for a bit (a number of follow-up changes were necessary), they are not part of the current first beta. They will be part of the next one, though.

#12 That's a great news.

it was clearly not an obvious bug!

#13 fixed in Beta 2