Game Development Community

Strange behavior in the world editor: apparent loss of focus.

by Chris Calef · in Torque 3D Professional · 04/12/2012 (8:38 am) · 2 replies

I'm having a weird and very annoying issue in my most recent builds, and am somewhat stumped. The behavior is this: when you first start Ecstasy Motion, the most of the keymap is disabled, as if the editor had focus on a control and it expected you to be typing into that control rather than using the keys to move. The arrow keys still move the player/camera around, but WSAD keys and space are disabled.

You can work around it by clicking in any text edit field and then clicking back in the scene, which is why it seems like it must be a focus problem, but I can't find any control that has focus or is receiving text. Does anyone have any idea how you could manually force the editor to put its focus in the normal place, or find out what control has focus at any given time?

Thanks!
NextNext Thread
PrevPrevious Thread
More from Torque 3D Professional


Associate Chris Calef
BrokeAss Games
#1
04/14/2012 (9:17 am)
OMFG, found it! Seven or eight HOURS later, after one of my most brutal, teeth-gnashing, head-pounding, brain-frying Torque days ever.

Turns out, there is a thing called KeyboardTranslation (from platformWindow.h):
/// @name Keyboard Translation
   ///
   /// When keyboard translation is on, keypress events that correspond to character input
   /// should be send as character input events rather than as raw key events *except* if
   /// shouldNotTranslate() returns true for a specific keypress event.  This enables the
   /// platform layer to perform platform-specific character input mapping.


I've never heard of that, and never needed it, but that was what was happening, to utterly wreck my first initial seconds of user experience. Wondering how the heck I accidentally turned that on, it turns out that when I added MLTextControls (in order to simply get a text box that handles multi-line, not to add any markup characters or anything fancy like that) it also turns on Keyboard Translation. This must be to handle the markup characters, I guess.

From guiMLTextEditCtrl.cpp:
bool GuiMLTextEditCtrl::onWake()
{
   if( !Parent::onWake() )
      return false;

   getRoot()->enableKeyboardTranslation();
   return true;
}

This is still a temporary fix, since I think the real problem here is not that the MLTextEditCtrl control turns on keyboard translation, but rather that my interface thinks that control is in charge right now. The weird thing is that even while my WSAD controls are not getting to the movement map, they are also not getting echoed to the MLTextEditCtrl itself, like would be the case if it actually had focus. It would have been easy to figure out if that was the case... But if I can find a way to get focus back where it is supposed to be, I can probably leave the MLTextEdits functioning as they are supposed to in the engine.

Cheers,
Chris

Associate Chris Calef
BrokeAss Games
#2
04/17/2012 (11:02 am)
Hehe, well, last update on this one, but it turns out my previous "solution" was great, [i]except[i] for the minor fact that it didn't just kill markup language functionality for the MLTextEditCtrls, but instead killed text input entirely.

Heh, oops.

But anyway, even though I'm not sure why KeyboardTranslation got left on in the first place, I've gone back and undid my fist naive attempt, and instead added a "disableKeyboardTranslation" console method to guiCanvas, and now I call that at program start, which seems to solve the problem without any collateral damage.