Support for native.newTextField

Solar2D Win32 Desktop
#81

Hm. Try changing line 639 from this:

if keyboard[keyName] and phase == "down" and not pressed[keyName] then

to this:

if keyboard[keyName] and phase == "up" then

That way, letters will only get passed into the text field when you lift your finger off the key. In my own testing, I was able to type relatively easily when they got dispatched on the “down” phase, but that phase does repeat itself if you leave your finger down, so it could be that your system repeats faster than mine, or it could just come down to a matter of preference. At any rate, that should eliminate the duplicate entries.

Thanks.

#82

I like your table setup for the characters. I used to upper function when isShiftDown for letters. It’s too bad to upper doesn’t work on numbers and symbols.

#83

Hi folks, don’t forget with access to the code one can always extend functionality to suit additional needs and wants.

#84

Where is the string library code? I looked through the Lua reference manual and Corona Docs… 

#85

@dagotron: the string library (http://www.lua.org/pil/20.html) is a native Lua library, not something that Corona Labs built or maintains. So I’m not sure the source code is available for it, but you might have luck by searching the web - though I suspect that it may not actually be written in Lua, but rather in some variant of C. But the documentation I linked to above should give you an idea of what it’s capable of and how to use it. And of course, you could always modify or add to it by declaring new functions that begin with “string.” (but proceed with caution, and be prepared for code that might not be “future proofed” should an updated version of Lua with a modified string library get released.) 

#86

hey guys, I’m not sure what version of the text input solution we’re talking about, but mine has code to convert all keys to upper-equivalent  if the shift key is down.

i.e. ‘Shift + 7’ == & 

-Ed

#87

Bwa-ha-ha-ha-ha-ha-ha-ha-ha-ha-ha!!!  :smiley:

   https://developer.coronalabs.com/release/2015/2695/

#88

@Joshua: diabolical!  :smiley:

Seriously, though - this is one heck of a daily build! Windows text input support, plus Mac App store compatible OS X builds. Nice work, engineers!

(However, just to save face, I will note that my workaround supported the “hasBackground” property.)  B)

#89

The custom text field you and Ed have made definitely have merit, for sure.

Oh and your test app (the one with the blue screen of death in the background :) ) proved useful in testing our new Windows TextField and TextBox support.  Thanks for posting it.

#90

Thanks for the kind words, Joshua - and glad to know that my little demo project was able to help out!

FYI, I’m just now uploading an update to the Twitter plugin that incorporates this new feature on the Windows Simulator. Previously to use the plugin in the Windows simulator you had to modify your code with an oAuth token string value and relaunch the project. Now I’m just going to prompt the user to copy and paste that token string directly into a textField, which makes for a faster and easier process. It’s still not as seamless as it’d be with in-simulator webviews (hint, hint  :stuck_out_tongue: ), but it’s a big improvement. Thanks for the good work on this!

#91

Yes, amazing work Corona staff! But this has got to be the worst “Gotcha!” in the Corona world, 

Native text boxes are not part of the OpenGL canvas and do not obey the display object hierarchy, so they will always appear in front of normal display objects including images, text, and vector objects.

I have a form that puts a question label and a comments textbox inside each row of a tableview… But it also has a top navigation bar, so when the user scrolls through the questions, the textbox hovers over the category row, top bar, everything!! Can’t we fix this limitation somehow?

#92

@tartar,

This has always been a problem with all native.* elements and I don’t think we’ll see a fix anytime soon.  The problem is you have objects controlled in two different ‘domains’ and no easy way to get them together.

However, if you’re doing this on windows (or OS X) you can always use Jason’s or my solution and just extend it to OS X.  I’m not sure about Jason’s solution, but mine checks if you’re in Windows.  You could simply change that to Windows & OS X and it would then use my variant for desktop and native.* for mobile.

Hope this makes sense.

#93

It makes sense… It’s just mind boggling that we can’t get those two domains to co-exist on the same plain… I may have to go full native and use visual studio to create this windows app. But I have implemented a solution with the display text and key events similar to yours and Jason’s… It looks better b/c I can give it rounded corners, on focus borders, etc,** but I do not like that it is not editable. So far the client hasn’t complained about it yet… :slight_smile:

**more importantly, it falls behind the top nav bar when you scroll the tableview! 

#94

Native and OpenGL objects can never truly co-exist. Though our engineers a while back did get it so you can insert native objects into groups, which lets you move the whole scene up to show the keyboard or allow Composer to take care of dealing with them.  Using fade or crossFace with native objects doesn’t really work since they never leave the screen area and would still be sitting on top, but any of the composer transitions that moves the object out of the viewing area will appear to work. And when you remove the scene it’s cleaned up accordingly. 

Rob

#95

I think I have found a solution to my problem! I almost forgot about widgetstown editField widget… Now that there is native textfield support, I can use that to display the text through display text and then it pulls a native textfield to edit text when clicked!