Composer.showOverlay() is covered by native.newTextField()

Hello experts,

I created a scene for overlay the code are below.  my problem is when the overlay poped-up it shows under or at the back of the textfield.  Yes I cant touch the textfield because its disable due to the overlay is active but the overlay seems at the back of the textfield which should be at the top or before the textfield…

can anybody know the way or idea how to resolved it?  thanks…


main.lua

local selectValue

local x, y, w, h = 20, 100, 300, 20

function selectValueListener ( event )

   local phase = event.phase

  if ( phase == “began” ) then

     native.setKeyboardFocus (nil)

     local options = {

             isModal = true,

             effect = “fade”,

             time = 100,

             params = { parentBoxX = x, parentBoxY = y, parentBoxW = w, parentBoxH = h }

      }

     composer.showOverlay( “dialog_x”, options )

  end

end

function scene:show( event )

   local sceneGroup = self.view

   selectValue = native.newTextField ( x, y, w, h)

   selectValue.anchorX = 0

   selectValue.anchorY = 0

  sceneGroup:insert ( selectValue )

  selectValue:addEventListener ( “userInput”, selectValueListener )

end


dialog_x.lua

function scene:create( event )

  local sceneGroup = self.view

  local bgX = event.params.parentBoxX

  local bgY = event.params.parentBoxY

  local bgW= event.params.parentBoxW

  local bgH = ( event.params.parentBoxH * 3 )

  local bg = display.newRect(bgX, bgY, bgW, bgH)

  bg.anchorX = 0

  bg.anchorY = 0

  bg:setFillColor (1)

  sceneGroup:insert( bg )

end

In Corona any API that starts with “native” sits on top of any other Corona display object.  Corona uses OpenGL to draw its graphics and both iOS and Android require that to be  behind any other UI objects, like native.newTextField()'s.  You should hide your text fields before you show the overlay and when the overlay closes, unhide them.

Rob

I ran into this exact problem and I had to manually make the native fields .isVisible = false when the popup was overtop and then manually reset .isVisible = true when the popup was gone.  Not perfect (if you can see the field) but it works.

yes… that was I’m thinking to hide it because I try and try by putting other display group but its the same result… that is why I’m thinking to hide it when the pop-up will open and hide it when it close but I did not do it yet until I will received your response due to maybe there is an other way…

thank you guys…  this is what I love in learning in corona 

How do you suggest making this look even half good when dealing with things like fading scene transitions? I have tried and an abruptly (dis)appearing native.newTextField()'s sticks out like sore thumb.

Hi @runewinse,

Well, you can’t fade these out, and if it really looks disruptive, then how about omitting the background fill of these objects and using transparent input fields? Or, put normal display objects (like basic rectangles) behind the transparent input fields, and fade out those with the scene? The text itself wouldn’t fade out, but at least you could control the “backgrounds” of them.

Another idea may be to slide the input fields off the screen, so at least they wouldn’t just instantly vanish.

Best regards,

Brent

How about this idea: You make a text input WIDGET  :slight_smile:

It is, as far as I know the number TWO issue on the request list. There is a reason for this. You’re kiling us with this native.newTextField stuff…  :mellow:

Hi @runewinse,

Is this what you’re looking for? I haven’t tried it myself, but it might be exactly what you’re looking for.

http://widgetstown.com/corona-sdk-addons/addons-info/widget-neweditfield-1-0/documentation/

Brent

Even the mentioned third party widget had sizing problems. Besides, using a thrid party solution that may or may not are updated is not how I want to do it. 

It is actually  your responsibility to make this easy for your customers.  YOU should do the effort to make a edit text widget, even it if is a big one.

The request for a widget text edit is the second highest ranking of all requests:

http://feedback.coronalabs.com/forums/188732-corona-sdk-feature-requests-feedback/suggestions/3577682-widgets-to-replace-native-textbox-and-textfield

Can you please show at least some respect for us paying users and recognize this as a major problem?

We are very aware of how much the community wants this.  But no one seems to understand (or accept) how hard this task is.  We can’t snap our fingers and make this happen.  This isn’t something we could have an engineer spend a couple of months on and have anything remotely useful that you would be happy with.

You’re right about that. it’s not easy to understand this.

There are FREE third party solutions out there that are more or less working (you (Brent) suggest one of them as a solution only a few posts above). 

The big question is this:

If someone can manage to make a widget editText from the “outside”, why is it such an inhuman task to do an “integrated” version and add it to the widget library?

You have all sorts of suggestions, hacks and tricks to make the newTextField working as good as possible. Why not implement all these nice tips yourself and add it to a widget?

I’m probably a bit dense, but I just don’t get it  :wacko:  

My understanding is that 3rd party solution is still using native.newTextField() under the hood.   We posted a blog post a while back that provided you a starting point to build your own widget.newTextField() implementing many of these enhancements.  But at the end of the day, there is still a native.newTextField() in play.  It has to live with the “always on top” rule and while it will transition with the group it’s in position wise, it doesn’t transition alpha wise which limits it’s ability to fully integrate.

The people asking for this want an OpenGL based text entry system which is so incredibly hard it would take a full team of engineers a couple of years to get working well because this would have to be created from scratch in a system not designed for this.  I tried once for a client to do a custom keyboard/text entry system.  In three months of work all I had to show was upper case only letters and the ability to add a character at the end of the string or erase the last character.  What was missing?

  1. Low case/symbol/shift state support.

  2. moving your finger between multiple character input

  3. holding down a key to show similar symboled keys

  4. emotes

  5. ability to edit within the string.

  6. ability to accurately predict where the end of the string was to draw the cursor

  7. copy/paste features

  8. spell check /  auto correct

  9. language support

  10. ability to support Right_to_left languages

  11. ability to scroll the text as the box filled up

and probably a bunch of other features that our customers would demand that a text entry system support.  On the list above, given more time, I could implement several of them (shift states, numbers, symbols etc.) but other things like editing in the middle of the string would be close to impossible to do because of the way text is rendered in OpenGL.  You would never get copy/paste.  Language support and such could probably be done, but it’s years of work to get right.

Apple and Google spent years developing their OSs.  Their text entry exists in a space that’s designed for it, not a “Graphics Rendering system” that’s not.  They both had a large team of developers working on it.  Today’s features like jesture input, copy/paste and other features came out in later iterations of the OS.  In other words it took their large teams years to do in an environment where its reasonable to do. 

If you can find an OpenGL text entry system that doesn’t use native.newTextField under the hood, I’d love to know about it.

Rob

Hi Rob,

Thanks for the long explanation. I do not know enough about this to have any meaningful views about OpenGL text entry systems.

All I (we) want is a text edit field that is (a lot) easier to deal with than what we have today. I don’t care what is in the bottom  :slight_smile:

If I have understood it correctly, the way most people handles this is using some “ghost textEditField” fields that is shown instead of the real native.newTextEditField. The native.newTextEditField is hidden until the user taps on the “ghost textEditField”. The “ghost textEditField” is then made invisible and the real native.newTextEditField is getting focus. When the editing is done and the native.newTextEditField loses focus, it is again made invisible and the “ghost textEditField” is made visible again.

This “ghost textEditField” is made of standard display objects and will, of course, follow any scene transitions, scrolling, group hierarchy etc.

As far I can see, the only problem with this is that you cannot with a tap inside the “ghost textEditField” place the cursor directly within the character string. You will have to tap it to let it have focus and to a second tap to select the text/place the cursor. There could be other drawbacks, but if this is all there is it’s a small price (for me) to pay for something that would look good.

Is it, for instance, possible to make a widget.newTextEditField that is based on native.newTextEditField but has a the above functionality built in? 

I don’t know. Maybe the ghost thing doesn’t work. I do not know enough about this. I can only dream and hope…  :smiley:

As far as I see only one of the two statements below can be true:

A ) It is possible to hack together something based on native.newTextEditField that works good

B ) It is not possible to hack together something based on native.newTextEditField that works good

If  A is true, then it should be possible for you to make a widget that does these things

If  B is true, then your marketing department should immediately remove all mentioning of “Business apps”

Hi @runewinse,

The basic functionality you describe (ghost field with native input) is not “impossible” but it faces the crippling limitations that you describe, so you would never be happy with it. You would not be able to click inside the “fake” (ghost) input field and gain any degree of accuracy on where the cursor should be. For example, what if the text inside the ghost field was “DDD” but then later you changed it to “III”? Obviously in the first example, the overall text is much wider because “D” is wider than “I”, visually. So there would be no possible way to determine cursor location, unless you built some complex data structure that somehow measured and stored the width of each letter and calculated the “between point” for each… but then imagine extending that outward to different fonts, different font sizes, different languages, etc. etc. Then – as if that isn’t complex enough – imagine extending that on to multi-line text boxes with additional lines, word wrapping, and all the rest.

Hopefully we have clarified the complexity of this task and described why we haven’t “just done it already”.

As for “removing all mention of business apps”, what exactly is so crippling about native text fields for you? As far as I can recall, you haven’t mentioned anything that can’t be done with native text fields except for fading them in and out (alpha) with transitions. What else about them is road-blocking your project so much?

Brent

Well, as I wrote above, that “crippling limitation” limitation is something I could live very well with, but I would understand if others might not. As I understand the long explanation above (which I understand completely) is to underline how difficult it would be to hit a specific portion of the text with a “direct tap”?

Yes and no.

I sort of understand why you cannot easily overthrow the native.newTextField widget altogether. Although why you have to make a completely new text entry system (keyboard) to replace it, is completely beyond me. But this is something that I do not know anything about so I’ll take your word for it.

What is not so clear (to me) is why there isn’t some alternative (ala the “ghost edit text”) for those who want a widget type of textField. It would have to be double tapped. So what? You just write a “Gotchas” section in the docs  :smiley:

First of all: I have not written many business type of apps so I have not a huge experience, but things that is annoying about the native.newTextField:

  1. The sizing problems (although these seems to be taken care of now (maybe even for us with public releases some time…)).

  2. All the other problems with the native.newTextField is caused by them not following the rest of the display objects.

2a. Fading/transitions of scenes

This is not only related to fading (as you mention), but as far as I know  all kind of scene transitions as you have to manually remove/make invisible the newTextField. It ends up looking very amaterurish. Please correct me if I’m wrong as I’d love to be.

Solution: Give up all transitions. Revert to abrupt scene changes.

2b. Scrolling 

When a newTextField has the unfortunate placement that it will be covered by the keyboard it has to be moved away. Typically this is done by scrolling an entire scrollField or group containing the whole GUI. This works for everything, but the newTextField. This will have to be handled separately. I have been able to make it scroll with the rest, but it lags a bit and I have never been able to make it look smooth/good.

Solution: Give up nice scrolling. Revert to sudden replacement. Or place all newTextField on the top half of screen.

2c. Covering popups/(non-system) messages/dialogues

This I have never tried myself, but I cannot see how these things can be made to (partially) cover newTextFields.

Solution: Not have these things at all because they might cover a newTextField.

As said before. I haven’t done much “business apps”. Maybe there are other examples that I haven’t thought of.

Are those points above “crippling/road-blocking”? Crippling is a strong word. “Very limiting” would be better. If I have to use a newTextField today I limit the placement to the upper part of the screen to avoid the keyboard etc. A still stubbornly use fade transitions between scenes today, but make them so fast that the newTextField hanging around looks as little bad as possible.

But I might be wrong about the points above. I could have misunderstood something. God knows it has happened before… :rolleyes:

2a.  It will transition with moving transitions as long as the textfield has been inserted into groups.  It’s only fading transitions that do not work. 

2b.  Actually, if you insert the text field into a display group, you can move the whole group as one and the text fields move with it.  This has been true for at least two public builds now.  See:  http://coronalabs.com/blog/2014/11/18/tutorial-moving-native-textfieldtextbox-objects/

In addition we are experimenting with a technique called “Panning” where we move the entire display up when the keyboard shows until the active textField is just above the keyboard.  This is working great on Android.  On iOS there are some pretty big limitations that we don’t know when we will get a chance to solve.  If you’re app is a fixed orientation app, it should work, if you’re app supports multiple orientations it doesn’t.  The idea here is to take control of the positioning in software which is what most native apps do. 

But since group scrolling works, 2b. shouldn’t be an issue.

2c. This is what I was talking about in my long post.  Your app is constructed of two “spaces”, the OpenGL canvas where all Corona “display.*” objects are drawn.  The widget library uses display objects pretty extensively, so you can consider they too are part of the OpenGL canvas.  The other “space” is native space.  This is where anything native.* and media.* draw their objects.  It always sits above the OpenGL canvas.  There is absolutely nothing we can do about it.  Native will always be on top of OpenGL.  On Windows (which is why we don’t even have a native.newTextField there…) Microsoft doesn’t even allow the native box to be drawn on top of the OpenGL box.  You simply can’t mix them in the same window.

In your solution you write:  Not have these things at all because they might cover a newTextField. But that’s not the case.  It’s Not have these things at all because that CANNOT cover a newTextField. 

Brent describe issues with ghost fields, but it’s even worse.  If you could have it off screen, I’m not sure how you would popup the keyboard without being able to touch the field in the first place.  This would be a bad user experience.  If you could have it off screen, then users would not be able to edit the text, which they would expect.  Touching the display text would provide no information to the native.newTextField to allow people to move the cursor in the middle of the screen, copy, paste, etc.  This would provide a worse user experience than having the field on screen and dealing with fading transitions.  If you could work out a way where the native.textField would come on screen while editing and then hide itself, there would be an unacceptable flicker and font differences that would cause this to also be unacceptable.

As I pointed out above, and I don’t want to repeat myself.  Building an OpenGL only text editing system would take a full team of engineers well over a couple of years to get working and even then, it would likely be very clunky because OpenGL is designed for output only and information about font metrics and such is not available.

What we have is the best that is humanly possible given the environment we work in.

Rob

OK, this is great news! Last time I really tried hard to make native.newTextField work I’m prety sure they we’re not allowed into scene groups at all (and certainly would not move with them).

I stand corrected then. But I’m glad for any improvement in this area!

Sorry for being so unclear. Instead of writing “they might cover a newTextField” I should have written “_they might be supposed to cover a _newTextField, but can’t”.

Again, sorry for being unclear. English is not my native tongue. But I suspect you kind of understood my point anyway - that this is a real world problem with native.newTextField to which there are no solutions. You asked for examples and I tried to provide you with some.

About the keyboard popup thing

I don’t understand this. I’ve bought WidgetCandy (no longer developed) and they do this. Widget Candy shows “ghost edit texts” and when you tap on them a native.newTextField pops up AND the keyboard pops up in the same go. In fact, this works much like my proposed “ghost edit texts” except that the native.newTextField pops up on the top of the screen instead of replacing the “ghost edit text”.

So how did that guy make this with just .lua files that I can use with my Corona Basic SDK? Or have I misunderstood what was the problem with the keyboard?

About touching the screen with the native.newTextField hidden

There was never talk of this, was it? As soon as the “ghost text edit” was touched, the native.newTextField should be made visible above it and thus getting all the following text manipulating touching. Then as soon as it lost focus it should be made invisible again.

The bold quote above

Of all you’ve written (and you do it well, by the way (and I’m not talking about only this thread)) this is bothering me, because what you say is that there is no way for you to know how a native.newTextField actually looks. That you cannot even pixel copy the contents of a native.newTextField. Not even take a partial screen dump of the contents of a native.newTextField.

Because if you could do any of that, you should be able to make a copy, use it as a texture and make a textured “ghost text field” rectangle that follows the “display rules”.

But if the native rendered objects are really that ungraspable I have to give up my quest for a “ghost field”  :mellow:

That said, I’ve learned a thing or two tonigt that I will take with me. native.newTextField working in groups being the most important. I will indeed try to get the best out of how it works today.

Thanks for the effort! The rest of Corona actually works prety well you know  :P 

Hi @runewinse,

I honestly recommend that you do not pursue this “ghost field” concept too intensively. Rob and I have mentioned the myriad of issues with it, and while you may get close to your preffered functionality, I don’t think you’ll ever create an ideal solution, and whatever the result is, it will still not be as feature-rich as native text fields. Yes, I suppose you could place an “invisible” ghost field directly over an OpenGL-modeled field, but it would face other limitations. How would you render the blinking cursor? And where would you place the cursor within the OpenGL field? You can’t detect “cursor is at X position of 34 within this native field” so the ghost field serves minimal purpose. And what about pressing and selecting text within the field? Not to mention the various other features of native fields which would be nearly impossible to mimic in an OpenGL-modeled version.


As a “final” point to everything said, I tinkered for about 10 minutes yesterday and achieved what I believe is a workable “fade out text fields” method… not perfect in every way, but quite plausible.

  1. Construct the native text field, and make its own native background hidden (one simple setting for the field).

  2. Place a Corona display-object rectangle (OpenGL; display.newRect() or display.newRoundedRect() ) behind the native field, making its background/border look as clean as possible. This gives you the added benefit that the text fields could be styled more to your liking, and also look almost identical across platforms.

  3. When the scene fades out, begin a Runtime or repeating-timer-based function which sets the color of the text within the native field (opacity/alpha is a valid entry in setting the native field’s text color). This function would repeatedly reduce the opacity of the text until it reached 0. Simultaneously, do the exact same opacity fade on the rectangle that you placed behind the field, effectively making it look like the entire field is fading out.

I realize this isn’t perfect, but it’s better than nothing. Some “gotchas” to this are:

  1. The native text can’t be faded out with a transition.to(), since setting the text color is a method, not a property setting.

  2. If you had some complex visuals below the two elements, there may be a little oddity in the fade, since the entire field isn’t being faded out as one unit. In other words, a very observant user may see some visual bleed from the background visuals through the rectangle on through to the text as it faded… but since the fade would probably happen in less than 1 second, it wouldn’t be too apparent.

Brent

I’m sure we’re talking “past eachother” here… “Feature rich”?

You seem to write about mimicing the behaviour and problems selecting text over and over again, but those “ghost field” was only meant to LOOK like a “inactive” text field. As soon as they are touched, the native field is to be taking their place and the next tap is the one placing the cursor or selecting text or whatever. It requires one extra tap, but advanced behaviour programming are needed.

If such an extra tap is something that an end user would expect is another matter… It could very well be that he would not…

I also see that there are certain problems related to how the field loses focus, but I was hoping you intelligent guys might find a way… :wink:

Ok. Thanks for the tip, Brent! I’ll look into it!

In Corona any API that starts with “native” sits on top of any other Corona display object.  Corona uses OpenGL to draw its graphics and both iOS and Android require that to be  behind any other UI objects, like native.newTextField()'s.  You should hide your text fields before you show the overlay and when the overlay closes, unhide them.

Rob