Support for native.newTextField

schroederapps · July 27, 2015, 9:32pm

It’s funny that this thread has popped up when it did, as I just last week started working on a module to add “faked” support for native.newTextField() and native.newTextBox() in the Windows simulator. Ed and I have corresponded on this, and it seems like he and I are taking slightly different approaches to the problem, so with his blessing (I didn’t want to steal anybody’s thunder or step on toes), I’m going to make my own solution available here, and on my website later this week, once I have time to compose a blog post around it.

There is a sample project that shows off the various methods and parameters you can apply or adjust to native text inputs attached to this post. You can load that up in the simulator to check it out, or if you want, just copy “windowsText.lua” from that sample project folder and require it into your own project.

The module is only lightly commented, but there is a “how to” section at the top of it. I’ve copied that text at the bottom of this post. The module is set up to overwrite the default native.newTextField() and native.newTextBox() APIs, so you don’t need to change any of your code to use it. If you are running in the Windows simulator, it’ll use the faked APIs - if you are running it on any other platform, it’ll use the native versions. But you can override this behavior by calling windowsText.enable() to force the faked versions on a non-Windows platform, and windowsText.disable() to revert back to the native APIs. The faked text input objects dispatch “userInput” events identical to those put out by their native counterparts, so if you have event listeners for your input fields, they’ll work just fine.

I probably won’t be doing too much support for this module, as it’s not something that would be used in a released app (it’s just a tool to enable text input in the simulator, after all), but if you find any bugs please let me know and I’ll do my best to fix them. In my testing, it works pretty much as advertised, though. Hope some of you find it useful!

-Jason

https://www.youtube.com/watch?v=sPIiMMSb_9E

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* windowsText module for Corona SDK Copyright (c) 2015 Jason Schroeder http://www.jasonschroeder.com http://www.twitter.com/schroederapps \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* ABOUT THE MODULE: This module was created to "fake" native text input on the Corona Simulator for Windows, which as of July 2015 does not support the native.newTextBox() and native.newTextField() APIs. You are welcome to modify it as needed, but it is set up to "just work" by requiring it into your Corona project. Once required, the module will check to see if the project is running in the Windows simulator, and if it is, it will overwrite native.newTextBox() and native.newTextField() with these non-native Windows simulator-compatible functions. These modified functions are fully compatible with all syntax and methods of their native counterparts, so you will not need to alter your code at all to support them. \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* HOW TO USE THE MODULE: 1.) Place windowsText.lua (this file) in your project's root directory (where your main.lua resides) 2.) Require the module by placing the following code in your main.lua: local windowsText = require("windowsText") 3.) That's it! Calling native.newTextField() or native.newTextBox() will now work in the Windows Simulator just like it does on-device or in OS X. 4.) If you want to use these non-native textFields or textBoxes outside the Windows simulator, you can optionally call windowsText.enable() to overwrite the native functions. You can revert back to the native APIs by calling windowsText.disable() if you wish. \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

[sharedmedia=core:attachments:4193]

john.armstrong · July 27, 2015, 10:38pm

This is so awesome… I made one quite similar last night. The only thing different that I am trying to implement is to slide the text to stay in view when it goes near the end for a single line textbox.

conor1 · July 28, 2015, 10:59am

This is very interesting, but I’m missing something. Running in build 2689 on windows, I can see the text field and textbox in your example, adjust them, but can’t type into them.

schroederapps · July 28, 2015, 2:17pm

Hi Conor, I was running build # 2689 in the demo video, so I know it works in that version of the Windows simulator. I know this sounds silly, but you are clicking on the textfield itself before trying to type, right? Just like native text fields and boxes on OS X, you have to click the text field prior to typing into it. A light blue border will appear around it when it is “clicked into.”

Also, are you using a US English keyboard? One limitation of this method of collecting input is that different keyboards would need to be accounted for, and by default, I only included support for a US English keyboard. You can add your own by creating a table of input values for a non-English keyboard (if you are using one). Just look at the structure of the “US_English” table in the module and use it as a template.

Let me know if any of the above helps you out. Thanks!

conor1 · July 28, 2015, 2:30pm

In your example, no light blue box appears. But when I implement it in my project, that box appears when I click it. But there’s no text input. I’m using a default text for the box, so it’s not empty at the start. Would that effect it?

I’m not using US_English, but I’m guessing that would only result in some different input results?

conor1 · July 28, 2015, 2:33pm

Another thought. Does using composer complicate things?

schroederapps · July 28, 2015, 2:37pm

Hi Conor,

Composer shouldn’t complicate things, at least in theory, but I haven’t tried using it inside of a composer scene, so I couldn’t say with absolute authority. I would suspect that the keyboard issue might be the likelier suspect (though I would not expect it to cause a complete lack of input - but I couldn’t say for sure).

It sounds like you dropped the plugin into an existing project. Have you tried running the sample project in the Simulator? Does that work for you? Just trying to get to the bottom of it…

conor1 · July 28, 2015, 2:40pm

I’m running your example straight out of the .zip. One correction, your example did have the blue box when clicking in.

I also tried changing my keyboard to US, and no different.

Your controls on text size work, so the textfield is being addressed.

Running windows 7.

schroederapps · July 28, 2015, 2:55pm

Hi Conor,

Here’s a way to check if it’s the keyboard issue. Starting at line 631 of windowsText.lua, you’ll see a function that listens for keyboard input and dispatches events only if there is a table entry in the keyboard table that matches the “keyName” that your keyboard puts out.

Update that “keyListener” function (lines 631 - 658) to the below. This modified function will print two lines to the terminal window every time you press a key on the keyboard. It’ll tell you the “keyName” of the key for your particular keyboard, and also if there is a corresponding entry in the keyboard table. If that second line says “Exists in keyboard table: false”, then you know that it’s a localization problem, and you’ll need to recreate a keyboard table sort of like the “US_English” one.

Here’s the updated code to replace the old keyListener function (paste in place of lines 631 - 658):

------------------------------------------------------------------------------------ -- LISTEN FOR KEYSTROKES AND DISPATCH CHARACTER ------------------------------------------------------------------------------------ function keyListener(event) local phase = event.phase local keyName = event.keyName local output if phase == "down" then print("Key pressed: " .. keyName) print("Exists in keyboard table: ".. tostring(keyboard[keyName] ~= nil)) end if keyboard[keyName] and phase == "down" and not pressed[keyName] then local default = keyboard[keyName].default local shift = keyboard[keyName].shift if not default == "backspace" then pressed[keyName] = true end if event.isShiftDown then output = shift else output = default end elseif phase == "up" then pressed[keyName] = false end if output then Runtime:dispatchEvent({name = "windowsText", character = output}) return true end end

conor1 · July 28, 2015, 3:19pm

Looks like function keyListener(event) is not being called when i press keys.

function windowsText.enable() is being called. Some form of disconnect on keylistener? Unfortunately I don’t have another windows machine to test on.

schroederapps · July 28, 2015, 3:21pm

OH! I think I know what this is. Are you using an Android skin in the simulator? For whatever reason, if you’re using an iPhone or iPad skin in the Windows simulator, key events don’t work. Could that be it?

conor1 · July 28, 2015, 3:26pm

That’s it, thanks.

conor1 · July 28, 2015, 3:27pm

But I’m getting double letters, numbers etc.

schroederapps · July 28, 2015, 6:22pm

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.

john.armstrong · July 29, 2015, 5:45pm

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.

roaminggamer · July 29, 2015, 8:42pm

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

dagotron · July 29, 2015, 10:19pm

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

schroederapps · July 30, 2015, 12:49am

@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.)

roaminggamer · July 30, 2015, 1:51am

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

Joshua_Quick · August 13, 2015, 11:26pm

Bwa-ha-ha-ha-ha-ha-ha-ha-ha-ha-ha!!!

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