InputField: how to detect mobile Cancel and Done buttons?

I'm using Unity 4.6.4f1 (but will move to 5 later) and JavaScript in an iPhone/iPad title.

I'm using an InputField (with the white editing box visible), and the iOS keyboard shows Done and Cancel buttons which I need to respond to (or else it feels broken—since I can't hide them).

Two questions:

1. Checking InputField.wasCanceled during Update() works fine. I coded various actions in response to that, including getting rid of the InputField using DeactivateInputField() followed by SetActive(false).

However... when I later re-activate that field a second time (SetActive(true) and ActivateInputField()) it immediately triggers wasCanceled again. As though it never stopped being in the "canceled" state.

(The deactivating/reactivating work fine—the field comes and goes and works perfectly, as long as I don't try to detect wasCanceled.)

So, how can I "reset" wasCanceled so the field can be used again?

2. How can I detect the Done button? I tried the End Edit event, but that doesn't detect the Done button specifically. It fires any time the user taps anything in my entire UI—including, I believe, Cancel. (In addition, End Edit seems to re-trigger instantly, the second time the field is used—the same problem as wasCanceled.)

Thanks for any advice/approaches to try!

Side note FWIW: I needed to prevent the disappearance of the iPhone keyboard when tapping buttons outside the field (such as my swatches of colors for the label being edited). I solved that by doing the following on Update()--which seems to work great:

if ( ! field.isFocused ) { field.ActivateInputField(); }​

That doesn't seem to impact my above inability to detect Cancel and Done; although it does make the keyboard pop back up after the unwanted "pseudo Cancel" happens. Which doesn't solve the problem of unwanted re-execution of all my code that's triggered by wasCanceled.​

 

I assume you need to check wasCanceled in the onEndEdit event.

Code (CSharp):

1. myInputField.onEndEdit.AddListener(() => { MyMethod(); });

However, I have a feeling that tapping outside the keyboard area will cause wasCanceled to be true and onEndEdit to be fired. You will have to check that. If so, maybe you could add

Code (CSharp):

1. myInputField.wasCanceled = false;

to the code that focuses on the InputField and or the code that checks if myInputField.wasCanceled == true.

The InputField.OnSubmit event should fire when the done button is pressed.

 

Thanks for the ideas! It turns out, though, that wasCanceled is read-only, so it can't be reset that way. Cancel does work the first time... but then messes the field up for all future uses.

(As for checking wasCanceled on End Edit: checking on Update is the documented example, and seems to work OK, but I'm sure your way would also work. Note: I observe that tapping buttons outside the field does not trigger wasCanceled, but does trigger End Edit.)

I can think of some awkward re-workings of my app that might work around this rough edge—such as respawning that InputField from a prefab over and over—but I hate to complicate my code (and the prefab that already contains the InputField) needlessly if there's an actual official way to detect Done and Cancel.

For now, in lieu of a solution, I have moved the above code that stops the keyboard from vanishing when other buttons are tapped: I put it on every individual button's TapDown, rather than the global Update loop.

That means Done and Cancel will now hide the keyboard (as you'd expect) even if I can't make them trigger other actions I'd like! Hiding the keyboard is useless because typing in this field is the whole point of the screen in question—however, having Done and Cancel do something feels less broken, so that's where I'm leaving it for now. (The user than has to exit the screen using my "back" button, and re-enter it to do more editing. Still weird, but I think I'm going to submit the app as-is for now.)

 

That's a shame. But did you try the OnSubmit event? It should detect the Done button, just as it detects a press on the return key (Windows), on a single line InputField.

 

Yes, that was one of the first things I tried, now that I think about it—so long ago I nearly forgot! But I just tried again to be certain. Sadly, tapping "Done" does not trigger a Submit event. (It seems like it should—maybe this is a bug?) I appreciate the ideas, though!

 

Did you ever find a solution to this problem?

I agree that the Submit event should trigger when touching the Done key on TouchKeyboards.

 

bump

 

bump