TOF : Keydown Trap Delete Key

1

On TOF there are a number of pieces of misinformation about this

in the ``` func textField(_ textField: UITextField, shouldChangeCharactersIn range: NSRange, replacementString string: String) -> Bool```

when you touch that key

  1. This event fires

  2. replacement String is EMPTY, it is not 0x08 or any other value

A backspace is detected by virtue of the fact that the event got called, not by the “value” of the key

This is not an XOJO error (other than lack of being properly documented), when in fact it is exactly how iOS was designed to react

2

For this to be reliable, it would require to know that this is the only key that produces an empty value, though.

3

and on iOS it is

4

Appreciate the thoughts @DaveS and yes, super easy to do under Obj-C and Swift. But alas this doesn’t work the same way under Xojo via MobileTextField:

  1. Let’s say a PIN field has a # within
  2. You press backspace to clear the #
  3. The KeyDown event gets called before the field is cleared
  4. The TextChanged event then gets called
  5. The field is now cleared
  6. Conforming to standard UX conventions a second backspace should take you to the prior PIN field
  7. There are now zero events that Xojo has to detect this next backspace as KeyDown, TextChanged or any others won’t be invoked with the backspace key

Today I did try a bit of a hack by using various Unicode spaces when the field is empty, but this wasn’t very successful, but I also didn’t try very hard.

Of course the true solution here would be to call out to textField:shouldChangeCharactersInRange:replacementString: within UITextFieldDelegate but this is probably more of a hassle than it’s worth at this point (from my side).

Ultimately this is a common place enough scenario that Xojo should solve this, regardless of the implementation, maybe similarly to how they have a ReturnPressed event.

5

Problably time to leave the Pricer Fish level toys of Xojo behind