newTextField with 'touch' listener

Audio and Graphics
#21

Hi @yosu,

What happens if you set the “isEditable” property to “false”? Does that allow touches to go through?

Brent

#22

Dear Brent, Here are my test results on an Android device. Do note that the ‘isEditable’ feature on newTextField() is not stated in the documents. It is only in the newTextBox()

 

#23

Hi @yosu,

Unfortunately, I think this would be tricky to workaround. It’s possible (but I haven’t tested it) that you could use a Runtime touch listener (on the entire screen) and try to sense touch movement on that. However, the text fields may even “shield” this (moved phases over their region) since they reside atop normal display objects.

Best regards,

Brent

#24

Dear Brent,

Thanks for the info. I am already using runtime listeners to track the page (scrollView) movement. It is mainly used to ‘hide’ and ‘show’ the text fields when it goes out of the scrollView. Sad to say, it cannot track it when the user touches the textField, as it is ‘always above’ the graphics.

Is this considered a bug, as ‘touch’ & ‘tap’ listeners does not work on the newTextField() ? If so, I will submit one.

Thanks

#25

Hi @yosu,

No, this isn’t a bug… the engineers confirmed yesterday that native objects intercept touch, by design. Personally, from a user standpoint, I would expect the fields to capture/respond if I tapped on them… but perhaps that’s just me. I realize that if you have a large amount of the screen filled with these (many rows of input fields) it will make scrolling difficult or impossible. Have you considered using visual “placeholders” that are not actually native fields until that placeholder is tapped on, then it shows a native input field in that location? Just a thought…

Brent

#26

Dear Brent,

I did consider using newRect() look-alike as replacements, then show the native text field once the user touches it. But my client prefers to have the nativeField visible, instead of a rect because the looks is slightly different (different people with their own favourites).

It would be quite hard to replicate a real native field look, as the mask and color has to be right.

You mentioned that ‘native objects intercept touch by design’. Does this mean that ‘touch’ listener should be usable ? Cause in my test, only ‘userInput’ listener is intercepted.

Thanks

#27

Hi @yosu,

To clarify, I meant that it intercepts touch events in general (at least this is what the engineers tell me, although if anybody has found otherwise, I’d be curious to hear more).

I agree that it would be difficult, but not necessarily impossible, to “fake” inactive text fields using regular display objects. In iOS7, they are white rounded rectangles, which may not be too tricky. But then, you’d have to style for Android too, if you’re going cross-platform, so it becomes a finicky process.

Brent