How can I detect (or implement) a "cancel" while entering text in a newTextField box?

[sieler2]

Hi…

I’m using native.newTextField to create a text editing box.

I am successfully displaying the box, and pre-filling it with my data, editing, and getting the result.  I.e., normal operations are fine.

 

The problem I’m encountering is that there seems to be no way to implement any kind of “cancel” or “abandon my edit attempt”.

 

If the user taps on my ‘cancel’ button, the cancel button handler is *not* invoked … but they’re out of the editing exactly as if they’d hit <enter>.

(The handler starts with: print ("cancel: " … event.phase), and I’m not seeing *any* activity for it in this case)

 

If, instead, the user taps anywhere outside the text box,

poof…it’s exactly as if they’d hit <enter>

(In the handler for the newTextField I start with “print ('edit: ', event.phase)”, and I am *not* seeing any event at that point other than ‘ended’.)

 

I.e., I can’t differentiate between <enter> and <tapped outside the box>,

which implies there’s no way to implement a ‘cancel editing’.

 

Perhaps the ‘ended’ phase event has some field I’m overlooking (e.g., ended_normally, or ended_by_tapping_outside)?

 

My goal: the user has started to enter an ID number into my app.  If he/she changes their mind, I want them to be able to cancel out of it.

 

(The obvious workaround, having the user edit the input to be, say, ‘cancel’, is onerous

 

Hmmm…perhaps I can obtain and check the x/y of where the tap occurred?

 

thanks,

 

Stan

 

[roaminggamer]

Stan,

Can you make a tiny standalone example showing this and zip it up, then link it here? 

That way we can see what  you’re doing that isn’t working.

From what I read you should be able to achieve your ends.

[roaminggamer]

Here I put a sample together solving the problem as I understood it.  Sorry if this is not what you meant.

Uses SSK, but that is not the point.  The key parts are the same with or without it.

https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2018/01/cancelText.zip

[roaminggamer]

Hey I read this again and I don’t think there is a difference between ‘enter’ and clicking outside a text field.

You need to provide your own qualification buttons as I have.

[sieler2]

Hi…here’s the source tarball and the .apk for Android (which I should have mentioned, sorry!)

BTW, on real Android, tapping outside the text box doesn’t close the editing like it does on the simulator,

so my question boils down to: how can a user abort/cancel entering text (other than by entering a special 

keyword like OOPS)?

Hmm…none of the 35 icons in the box above this text are “upload a file”

(There’s “My Media”, but (a) it’s not media, and (b) it’s empty when I search it

So, here’s the source: http://sieler.com/testedit/
 

thanks,

Stan

[anaqim]

create an invisible “catch all” surface that covers all but the field being edited.

when the user press “enter” you can cancel the surface and accept the input

if the user press outside the box, you can null the textbox input before removing the surface

if you are editing content and want to just cancel the edit, you store the old content on first access and when user touch the surface, restore the old value before removing the surface.

hope that makes sense, i do it all the time

EDIT - this way the user experience is that to cancel you touch outside the text field, which is expected behaviour, or enter to accept

[roaminggamer]

@siesler2,

Click the ‘more reply options’ button BELOW the posting area to get a upload option.

[roaminggamer]

Great suggestion @anaquim

I updated my first example to allow clicking outside the box to effectively cancel the edit of the current field.

https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2018/01/cancelText2.zip

Tip: This example is probably not 100% correct.

You should probably remove the catcher on each ‘ended’ phase in the text listener, to catch the close keyboard case.

[sieler2]

@roaminggamer’s code example was wonderful!

I learned a lot from his example, thanks!

(I also have questions now, like: why isn’t there a getvbuf in addition to setvbuf?  

And, what’s the default/initial value of buffering? : )

I now know that the simulator differs from a real Android in an important sense here …

on the simulator, tapping outside the text box *sends an ‘ended’ event to the text field handler …

on an Android, it doesn’t!   

Sigh.  That’s why I thought this couldn’t be done straightforwardly.

I’ve attached a version of his cancelText2, canceltext3, slightly stripped down (no need for the extremely interesting SSK files),

but which will display a running commentary of events to the app screen. My version has a “reset text fields” button to reset the three fields to their default values, and a “clear messages” button to clear the debugging output messages from the screen.

Apologies for the spacing changing…I ran the source through an analysis utility of mine that also reformats (as well as emitting ‘forward function’ lines) and accidentally started using that as the basis for adding more testing code.

That utility called out several things I wasn’t aware of, so I’m very happy I ran it!  

I’d not known about “isHitTestable” (a horrible field name : )  … I’d’ve called it isHittableWhileInvisible, perhaps)

Memory usage wise, I’d probably keep the cancel object around, changing the isHitTestable field to false when I want to “deactivate” it.

BTW, it’s interesting to note the difference between “ended” and “submitted” on a textField.   To easily see it, run the canceltext3 app and tap in field 1, type a few chars, then tap on field 2 (you’ll see an ‘ended’ was received for field 1).  Enter a few chars and tap ‘Done’ (you’ll see a ‘submitted’ was received for field 2, and you’re left still editing field 2).

Oh, the messages scroll in the opposite direction one would wish, so that the most recent is at the top … and visible even if a keyboard pane is being displayed.

thanks again,

Stan

[roaminggamer]

Stan,

Can you make a tiny standalone example showing this and zip it up, then link it here? 

That way we can see what  you’re doing that isn’t working.

From what I read you should be able to achieve your ends.

[roaminggamer]

Here I put a sample together solving the problem as I understood it.  Sorry if this is not what you meant.

Uses SSK, but that is not the point.  The key parts are the same with or without it.

https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2018/01/cancelText.zip

[roaminggamer]

Hey I read this again and I don’t think there is a difference between ‘enter’ and clicking outside a text field.

You need to provide your own qualification buttons as I have.

[sieler2]

Hi…here’s the source tarball and the .apk for Android (which I should have mentioned, sorry!)

BTW, on real Android, tapping outside the text box doesn’t close the editing like it does on the simulator,

so my question boils down to: how can a user abort/cancel entering text (other than by entering a special 

keyword like OOPS)?

Hmm…none of the 35 icons in the box above this text are “upload a file”

(There’s “My Media”, but (a) it’s not media, and (b) it’s empty when I search it

So, here’s the source: http://sieler.com/testedit/
 

thanks,

Stan

[anaqim]

create an invisible “catch all” surface that covers all but the field being edited.

when the user press “enter” you can cancel the surface and accept the input

if the user press outside the box, you can null the textbox input before removing the surface

if you are editing content and want to just cancel the edit, you store the old content on first access and when user touch the surface, restore the old value before removing the surface.

hope that makes sense, i do it all the time

EDIT - this way the user experience is that to cancel you touch outside the text field, which is expected behaviour, or enter to accept

[roaminggamer]

@siesler2,

Click the ‘more reply options’ button BELOW the posting area to get a upload option.

[roaminggamer]

Great suggestion @anaquim

I updated my first example to allow clicking outside the box to effectively cancel the edit of the current field.

https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2018/01/cancelText2.zip

Tip: This example is probably not 100% correct.

You should probably remove the catcher on each ‘ended’ phase in the text listener, to catch the close keyboard case.

[sieler2]

@roaminggamer’s code example was wonderful!

I learned a lot from his example, thanks!

(I also have questions now, like: why isn’t there a getvbuf in addition to setvbuf?  

And, what’s the default/initial value of buffering? : )

I now know that the simulator differs from a real Android in an important sense here …

on the simulator, tapping outside the text box *sends an ‘ended’ event to the text field handler …

on an Android, it doesn’t!   

Sigh.  That’s why I thought this couldn’t be done straightforwardly.

I’ve attached a version of his cancelText2, canceltext3, slightly stripped down (no need for the extremely interesting SSK files),

but which will display a running commentary of events to the app screen. My version has a “reset text fields” button to reset the three fields to their default values, and a “clear messages” button to clear the debugging output messages from the screen.

Apologies for the spacing changing…I ran the source through an analysis utility of mine that also reformats (as well as emitting ‘forward function’ lines) and accidentally started using that as the basis for adding more testing code.

That utility called out several things I wasn’t aware of, so I’m very happy I ran it!  

I’d not known about “isHitTestable” (a horrible field name : )  … I’d’ve called it isHittableWhileInvisible, perhaps)

Memory usage wise, I’d probably keep the cancel object around, changing the isHitTestable field to false when I want to “deactivate” it.

BTW, it’s interesting to note the difference between “ended” and “submitted” on a textField.   To easily see it, run the canceltext3 app and tap in field 1, type a few chars, then tap on field 2 (you’ll see an ‘ended’ was received for field 1).  Enter a few chars and tap ‘Done’ (you’ll see a ‘submitted’ was received for field 2, and you’re left still editing field 2).

Oh, the messages scroll in the opposite direction one would wish, so that the most recent is at the top … and visible even if a keyboard pane is being displayed.

thanks again,

Stan