native.newTextField inside widget.newScrollView is this possible?

Other
#1

I have a really long form that I need users to fill out on their tablets, right now I’m focusing on iPads. At first I thought I could just use a scrollview with a mask and insert my native.newTextField objects into there. I know how native display objects are and understand their nature. But I was wondering if anyone has found a work-around, or CL staff is there something on the horizon that will fix this? Like better native objects?

Right now I have my native.newTextFields scroll with the scrolling of the scrollView(using “contentTouch” and “endedScroll” events) and once it reaches a certain y value I set the textField’s alpha to 0 or make it re-appear. This works but looks a little klunky and after awhile the code will become a mess having to handle all the newTextFields scrolling and visibility. Is there another way of doing this???

I even bought Widget Candy hoping their Input Boxes could scroll, and while they do, they are only meant for small amounts of text. Once you get more then a sentence or two the lag while typing makes it a poor solution for my needs. They also don’t have a multi-line input box. I have since sent them an email so hopefully they can fix their inputs to handle more text and offer a multi-line solution.

For us who are building business apps have you found a solution for the above issue? How can you have users input text for a large form using a scrollview when the textFields can’t be used inside a scrollview? [import]uid: 58885 topic_id: 34512 reply_id: 334512[/import]

#2

native.* are “native”, they are not part of the OpenGL system and cannot be managed by any Corona Display, Widget or Storyboard APIs. They will sit above any display object. You will have to move them on your own.

[import]uid: 199310 topic_id: 34512 reply_id: 137269[/import]

#3

I understand that, I was just wondering if there was perhaps another approach. Moving the objects manually works in the simulator but not on the device using the “contentTouch” event. So even moving the native display objects manually is proving to be a no go. [import]uid: 58885 topic_id: 34512 reply_id: 137274[/import]

#4

I just recently did an app where I needed to do this. In your native.newTextField’s listener, during the “began” event phase I did something like this:

local function slideFormUp()  
 transition.to(screenGroup, {time=500,y=formGroup.y - 70})  
 transition.to(emailField, {time=500,y=emailField.y - 70})  
 transition.to(passwordField, {time=500,y=passwordField.y - 70})  
 slidUp = true  
end  
 if ( "began" == event.phase ) then  
 -- This is the "keyboard has appeared" event  
 if not slidUp then  
 slideFormUp()  
 end

or something like that.

[import]uid: 199310 topic_id: 34512 reply_id: 137278[/import]

#5

Thanks for your reply Rob, but that’ll make the textfields slide up when the keyboard is shown/started editing a textfield. I need the textfields to scroll in a scrollview, that’s the manual movement I was talking about. I don’t think its possible to have a large scrolling form with textfields unless I do something like use display.newText on top of an image that looks like an input (inside the scrollView) and have a nativeTextfield appear above they keyboard when they tap the faux input in the scrollview. This would give me the scrolling content I need and allow the user to input text without having to deal with getting native.textFields to scroll inside a scrollView. It would be similar to how messages app on iPhone works(input/textfield above keyboard). I suppose I can break the form up into different screens to avoid scrolling all together but on different devices and screen sizes this approach might be a bad one. [import]uid: 58885 topic_id: 34512 reply_id: 137283[/import]

#6

You could probably use a Runtime enterFrame listener that polls the Y position of the scroll view and move the native fields with them. I know this isn’t optimum.

The other thing that people do is to use display.newText for showing the text on the screen and have the field actually off screen. That may be your better option.
[import]uid: 199310 topic_id: 34512 reply_id: 137286[/import]

#7

native.* are “native”, they are not part of the OpenGL system and cannot be managed by any Corona Display, Widget or Storyboard APIs. They will sit above any display object. You will have to move them on your own.

[import]uid: 199310 topic_id: 34512 reply_id: 137269[/import]

#8

I understand that, I was just wondering if there was perhaps another approach. Moving the objects manually works in the simulator but not on the device using the “contentTouch” event. So even moving the native display objects manually is proving to be a no go. [import]uid: 58885 topic_id: 34512 reply_id: 137274[/import]

#9

I just recently did an app where I needed to do this. In your native.newTextField’s listener, during the “began” event phase I did something like this:

local function slideFormUp()  
 transition.to(screenGroup, {time=500,y=formGroup.y - 70})  
 transition.to(emailField, {time=500,y=emailField.y - 70})  
 transition.to(passwordField, {time=500,y=passwordField.y - 70})  
 slidUp = true  
end  
 if ( "began" == event.phase ) then  
 -- This is the "keyboard has appeared" event  
 if not slidUp then  
 slideFormUp()  
 end

or something like that.

[import]uid: 199310 topic_id: 34512 reply_id: 137278[/import]

#10

Thanks for your reply Rob, but that’ll make the textfields slide up when the keyboard is shown/started editing a textfield. I need the textfields to scroll in a scrollview, that’s the manual movement I was talking about. I don’t think its possible to have a large scrolling form with textfields unless I do something like use display.newText on top of an image that looks like an input (inside the scrollView) and have a nativeTextfield appear above they keyboard when they tap the faux input in the scrollview. This would give me the scrolling content I need and allow the user to input text without having to deal with getting native.textFields to scroll inside a scrollView. It would be similar to how messages app on iPhone works(input/textfield above keyboard). I suppose I can break the form up into different screens to avoid scrolling all together but on different devices and screen sizes this approach might be a bad one. [import]uid: 58885 topic_id: 34512 reply_id: 137283[/import]

#11

You could probably use a Runtime enterFrame listener that polls the Y position of the scroll view and move the native fields with them. I know this isn’t optimum.

The other thing that people do is to use display.newText for showing the text on the screen and have the field actually off screen. That may be your better option.
[import]uid: 199310 topic_id: 34512 reply_id: 137286[/import]

#12

Hi Rob:

I put native.newTextField on a widget.newScrollView, and the strange thing happened, that newTextField can be scrolled, I try this on HTC Desire V and Acer  Iconia A1-810, both of them can be moved by newScrollView, I use the 2013.2100 version SDK. Is it my good luck or corona sdk had started supporting this issue ?

I only tested this issue on two android platform without any problem, I want to confirm native.newTextField still had problem to put on newScrollView or not ?

Thanks

#13

I don’t see how this is possible.  widget.newScrollViews are display groups.  Native.* API objects cannot be inserted into a display group.  If we have been able to work that out, we would be singing those praises quite loudly.  I’d love to see a sample app where this is working.

BTW Build 2100 is two release builds old.  The current release build is 2189a and has significant widget fixes since 2100.

#14

Yes, the last time that I tested, the Android native.newTextField was obeying to transition, but iOS wasn’t.

If you want to be safe and more cross, I suggest to use the widgetstown.com editText. It has some fontScale problem, but unfortunately we don’t any better solution with Corona.

I was working on a textField 100% widget made and I made a good progress. But then I faced one problem: I would have to disable the auto grammar correction and Corona does not give access to that property.  

#15

Thanks for your update, Native API can be scrolled in Android and not in iOS, it is very important information for me.

And, Wow, that is very great news for textField 100% widget made. Looking forward for this good news update.

Thanks

#16

Hi Rob:

I put native.newTextField on a widget.newScrollView, and the strange thing happened, that newTextField can be scrolled, I try this on HTC Desire V and Acer  Iconia A1-810, both of them can be moved by newScrollView, I use the 2013.2100 version SDK. Is it my good luck or corona sdk had started supporting this issue ?

I only tested this issue on two android platform without any problem, I want to confirm native.newTextField still had problem to put on newScrollView or not ?

Thanks

#17

I don’t see how this is possible.  widget.newScrollViews are display groups.  Native.* API objects cannot be inserted into a display group.  If we have been able to work that out, we would be singing those praises quite loudly.  I’d love to see a sample app where this is working.

BTW Build 2100 is two release builds old.  The current release build is 2189a and has significant widget fixes since 2100.

#18

Yes, the last time that I tested, the Android native.newTextField was obeying to transition, but iOS wasn’t.

If you want to be safe and more cross, I suggest to use the widgetstown.com editText. It has some fontScale problem, but unfortunately we don’t any better solution with Corona.

I was working on a textField 100% widget made and I made a good progress. But then I faced one problem: I would have to disable the auto grammar correction and Corona does not give access to that property.  

#19

Thanks for your update, Native API can be scrolled in Android and not in iOS, it is very important information for me.

And, Wow, that is very great news for textField 100% widget made. Looking forward for this good news update.

Thanks