@Joshua: diabolical! 
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)
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.
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 
), but it’s a big improvement. Thanks for the good work on this!
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?
@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.
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… 
**more importantly, it falls behind the top nav bar when you scroll the tableview!
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
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!
Using “native” Windows TextFields/TextBoxes in a Windows game is highly unusual. Most games don’t do it for a reason. The main reason is that you can’t render native Windows UI while a game is rendering fullscreen. At least not without putting it into borderless maximized window mode, in which case, you can’t take full advantage of the video card. I suppose for a non-fullscreen app it would be fine if we can get OpenGL rendering to “clip” where the native UI is displayed at (prevents your game from rendering on top of the native UI).
In my opinion, for a Windows or Mac based game, I think it would be better to implement text input like how it works on consoles. Just display a virtual keyboard that players can use for text entry. You can use the up/down/left/right or letter key events. For example…
http://help.support.ubi.com/images/ACIV/ULC/ULCRedeemCode3602.png
And we’re thinking that game controller support is the next high priority feature to implement on Windows.
Ok, maybe the topic is misleading. I don’t realy need a support for “native” Windows textfields. I just need a way to get text input from the player.
For example the nickname in the Highscore, credentials for a Registration / Login form, or even the possibility to chat with other players. These are common features in a bigger multiplayer game.
A “console” like approach isn’t really what we want. It’s a bad user experience in a PC Game.
I could build my own textfields but the current properties of the “key” event aren’t helpful. I dont’t see any support for different keyboard layouts. Is it possible to get the pressed character?
Have you looked at the KeyEvent’s sample app? https://github.com/coronalabs/samples-coronasdk/tree/master/Hardware/KeyEvents
(its also part of your SDK under SampleCode/Hardware/KeyEvents.)
When you press a letter on the keyboard, you get two events a “down” phase and and “up” phase. There isn’t a reason you couldn’t build your own input if needed.
Rob
Hi Rob,
the problem with the “key” event is the missing support for different keyboard layouts.
If I press the “Ü” Button on a german QWERTZKeyboard, this is what I get:
{ descriptor = ";", isAltDown = false, isCommandDown = false, isCtrlDown = false, isShiftDown = false, keyName = ";", name = "key", nativeKeyCode = 186, phase = "up" }
This isn’t helpful at all. Our game will be localized in many different languages, so we need the support for different layouts and characters.
We’re not planning on adding text entry support in the near future.
Game controller support is our next highest priority feature.
I still recommend that you roll your own console-style text entry screens. A lot of modern games that are ported between consoles and PC have them and gamers have learned to accept them. Especially if the game supports game controllers.
Hi guys,
it’s me again 
I have another question, what are the plans for the Enterprise version and the possibility to build our own plugins for win32 (native, not pure lua)?
Could this be a solution to build our own text input fields?
Thanks
Corona Win32 apps supports plugins now via the newest daily builds. We haven’t announced it yet, but we were planning on doing so next week.
First, any Win32 plugins available to the Windows version of the Corona Simulator will automatically be included in the Win32 app build. For example, this includes the OpenSSL, Zip, and Bit plugins. This also includes pure Lua based plugins as well, but I don’t think we have any on the plugin store yet (the intent was to distribute shader plugins in this fashion). Also, please note that the existing zip plugin has Win32 Unicode path issues, which turns out to be an issue with the 3rd party open source zlib library that it’s currently using. That might be a deal breaker for you.
Regarding making your own Win32 plugins, while we don’t have any official documentation for it *yet*, it is absolutely possible to create them now. The newest daily build of Corona Enterprise provides the Win32 *.lib files and *.h header files you need.
And the header files can be found under…
CoronaEnterprise\Corona\shared\include
You can find the *.lib files under…
CoronaEnterprise\Corona\win\lib
You’ll need Visual Studio 2013 to create your plugin DLL. I recommend using the free Community Edition provided that your organization meets its terms (ie: for example, it’s not free for organization that make more than $1 million in revenue). You’ll need to do the following to create your plugin:
The standard Lua library (not made by Corona Labs) has built-in support for loading DLLs via the Lua require() function. It’s documented on the www.lua.org website. But here’s a quick summary. Your DLL needs to export a C function like this…
extern "C" \_\_declspec(dllexport) int luaopen\_plugin\_\<YourPluginName\>(lua\_State\* L)
You can find an example on how this works via the link below. It’s our “bit” plugin that we’ve open sourced on gihub.
https://github.com/coronalabs/plugins-source-bit
There’s just one more thing to note. We current haven’t made our Win32 specific C APIs public yet since that’s still in flux at the moment. But we do plan on opening it up in the near future (no specific date yet). If your plugin needs access to the main window’s HWND and Window messages, and I suspect it does, then a simple solution to this would be to get a hold of the main window’s HWND via Microsoft’s GetActiveWindow() C function. That’s a safe assumption to make for a Win32 built app (but not a safe assumption in the Corona Simulator).
https://msdn.microsoft.com/en-us/library/windows/desktop/ms646292(v=vs.85).aspx
Also, when you set your WindowProc callback to capture IME messages in your plugin, make sure to maintain the WindowProc *chain* by passing any messages your plugin doesn’t handle to the previously set WindowProc callback (which would be Corona in this case). Otherwise, your plugin will steal messages from the app, preventing Corona from receiving key and mouse message/events, and worse, the close message/event which allows the [x] button to close the app.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms644898(v=vs.85).aspx
Edit: Final note. Your compiled plugin DLL and all of its DLL dependencies (if any) will need to be copied to your app’s root directory, where your *.exe all of Corona’s DLLs are located.
I hope this helps!
Oh wow. These are awesome news! A big thanks for the guide, we will try it soon.
I think this will help us a lot!
I know that you said that native text fields are basically not going to happen however I would just like put in our request for them.
We have a newsletter signup form in our adventure games, as well as puzzles that use text entry. For instance typing in a password on a computer or searching for something in a Glitch Search box.
A virtual keyboard would be fine for a touch screen or a console, however I think it just seems strange that we would require that on a Windows machine that is basically guaranteed to be connected to a physical keyboard.
We’ve now got our adventure games working on the Mac builds, and the native keyboard works fine in there. Is there any chance for native text fields in the Win32 builds?
The current plan is to implement game controller support next. That’s the next most hotly demanded feature.
If you only need to support English text input, then you can do what Rob suggested and use key events. But you can really only support numbers and English letters with this technique. It’s not safe to assume what the shift key will do with the number and symbol keys because the character it’ll produce will differ between different region keyboards. For example, the $ sign will be above the 4 key on US English keyboards, but not on European keyboards (naturally).
If you need international text entry support, then perhaps you and @waldemar can work together on this. I’ve already shown @waldemar how to make a Win32 plugin.
For some parts we only need english text input but for others we need email address, so yea things get trickier for the latter.
I don’t particularly want to get into plugin dev right now, especially as I don’t have a windows machine to work on.
@waldemar - are you expecting to be able to release a plugin?
In most of our games we need text input (player name, password…).
Corona not supporting it for Windows and Mac is a huge disappointment.