The UITextField protocol function:
"textField: shouldChangeCharactersInRange: replacementString:"
was sometimes called with empty replacementStrings on key press
releases on keyboard. That triggered a backspace keyboard char to
be sent which caused problems when trying to remap actions to
other keyboard keys. No matter which key you were pressing the
resulting key would always be the backspace key.
Only handle text input using the UITextField protocol function
when the replacement string isn't empty. Handle all deletes through
the UITextInput protocol function "deleteBackword".
This has been tested in both cases when the UITextField is empty
(but GUI text field has text) and when the UITextField has text
(which has been added using the SoftKeyboard).
It has also been tested on Apple TV where a software keyboard is
shown with a big text field.
Instead of register input based on if hardware is connected or not
register input based on backend capabilities.
Mouse support is default supported through touch events on screen
(iOS) or touch on controller (Apple TV), and through connected
mouse hardwares. Gamepad controllers are supported from iOS 14 and
later.
Register mouse and gamepad input based on above capabilities to be
able to map actions to buttons on these input devices.
Keyboard support is to be added but not in this commit.
Remove the "isConnected" methods for each input and change the same
method for game controllers to a "isSupported" function to deal
with the iOS version support.
Remove the sending of the EVENT_INPUT_CHANGED event due to the
above reasons. The overide of the isConnected property function is
also removed due to this reason. It caused problems that key
mappings were reset on connections/disconnections.
The gamepad controller dpad button vaule change handler callback,
also called for the virtual controller dpad buttons, sent events
also for buttons not being pressed or released.
E.g. when the left dpad button was pressed an event was sent,
JOYSTICK_BUTTON_DPAD_LEFT with value 1 meaning it's pressed DOWN.
However, the other dpad buttons also did send their events but with
value 0 meaning UP. This had no impact for most of the games but
"The Griffon Legend" handles the dpad events a bit different where
the character is kept moving when the button is released. It meant
that the engine was triggering movements on both the event
EVENT_CUSTOM_ENGINE_ACTION_START and EVENT_CUSTOM_ENGINE_ACTION_END.
This commit changes the dpad button input handling so it remembers
the current state for UP/DOWN and LEFT/RIGHT. This ensures that only
the button that changes state is triggering an event.
The UITapGestureRecognizer is used to identify taps with two fingers,
sending an ESC key event. The UITapGestureRecognizer will not stop
touchesBegan from being called when doing a touch with two fingers.
Touching with two fingers when _mouseClickAndDragEnabled is enabled
will send a EVENT_RBUTTONDOWN.
But if doing a double tap the UITapGestureRecognizer with two fingers
will cancel the touchesEnded from being called meaning that no event
EVENT_RBUTTONUP will be sent to the engine. In some engines, e.g.
lure, this will cause problems since the engine might wait for mouse
clicks to be released before processing other events.
Fix the scenario above by introducing a delay of sending the event
EVENT_RBUTTONDOWN. If the UITapGestureRecognizer is triggered before
this timeout it will cancel the EVENT_RBUTTONDOWN by overwriting the
_queuedInputEvent with the ESC key event.
This commit also deletes the legacy implementation handling double
tap with two fingers to trigger an ESC event.
This happens on screeens with an xstart offset (= a screen
that is wider than 320 pixels, after some scrolling) but only
when there is dialogue text on screen when pressing F5.
Can be tested right at the start on the bridge. Just right-
click the sign, then press F5...
