Hi,
Any tips or suggestions on making a textField have the same look and feel as the rest of the application?
This is for a desktop win32 app. The rest of the app looks great, but it seems there is no way to customize a textField.
It mars a great looking application.
Thanks.
Herb
A native component it is not technically part of Corona and is drawn by the OS.
Looks like Roaming Gamer has just what the doctor ordered…
https://github.com/roaminggamer/RGEasyTextField/
I will give this a try
Ah yes I forgot about that… It takes a lot of code to pretend to be a text field just so it can be styled a bit. It is a shame the framework doesn’t use a similar methodology.
Jason Schroeder also has an interesting one that replaces native.newTextField with his own version.
It would make a lot of sense for him to probably sell that in the marketplace.
ok,so I’m going out on a limb here but why is it so hard to get a corona api for text input that is not native?
what about a widget for it?
this win32 limitation is really bugging me and i dont really want to have to build a lot of code around it just to get a simple text input box.
anaqim
Why is this hard to build an OpenGL text field? If we had a large team of engineers and years to make it, then it might be possible. Several people got a reasonable English only version working after we enabled keyboard handling. But this isn’t going to work on iOS or tvOS since there isn’t key events.
If you’re on a touch screen device, you have to build your own keyboard. Okay easy enough some display.newRect’s and touch handlers, but you still have to build a lot of support around being able to show and hide the keyboard and other things you may take for granted by the native text field.
Regardless, you have to support shift states to get upper and lower case characters. You are going to need to support symbols which is different between Windows and Mac. For English this isn’t bad, but are you going to support other keyboards? French? German? Simplified Chinese? Now the scope of building these keyboards grows by magnitudes. The data we get back is keycodes and shift states. You still have to figure out if someone has a French keyboard and generate the right glyphs. Now factor in right-to-left languages. You have to support that and the rules that go with it. Typematic rates? Editing in-line? Selecting? Copy/Paste?, Shift-Enter to go to a new line?
While individually these are addressable and you personally may not need all of these features, we would have to support them because our product is used internationally by developers and internationally by customers of those developers.
At least three people I know of had a simple English only keyboard working. Jason may have been one of them. But as far as I know all of them were abandoned over some reason or another (based on lack of chatter about it in the forums since their attempts).
I wish this was easier, but it’s simply not.
Rob
Hi Rob,
What your saying makes a lot of sense.
anaqim - I have contracted Jason Schroeder to build a texfield that is working really well in win32 apps by clever use of display groups.
He is adding some bells and whistles to it at the moment, but its already working very well for me.
I am not sure if Jason plans on selling this in the market place, I will find out, but I think widgets for win32 apps will become more in demand.
Herb
@Rob,
Thats a mighty explanation that technically is beyond me, so I am glad I started by saying I might be going out on a limb.
I only know that textfields was no problem in the previous system I was using (GameMaker Pro).
Thanks for clearing this up.
As I am on my second Win32 app built using Corona this is something I would absolutely both be interested in as well be ready to pay for. If you have a forum link or anything i can tag to follow i’d love to receive it.
Thanks guys!
Have a great day!
Anaqim
Replying partly just to “follow” this thread…
Herb is very kind, and I’m glad the module I made for him is working. I can see myself converting it to a plugin, as Herb has suggested since our first correspondence, but bear with me as it may take a bit longer than you’d think. First I want to finish up the “bells and whistles,” but then turning it from a “one-off” module to a one-size-fits-all plugin will take a while. I’ll need to document it, which takes time, then there is the Corona submission process, which can take some time depending on the number of submissions they are digging through.
tl;dr: plugin is coming but please be patient with me. 
I just got some idea which I’m gonna try tonight (at day job atm).
create a graphics input box
put the native.textfield offscreen
clicking the graphic input box will set focus to the offscreen textfield
typed textfield.text is then mirrored back to the graphics input box
the experience could be good, if it works
anaqim
I tried it and it works great 
crude code:
search=native.newTextField(581,28-200,288,30)
search_substitute=display.newText({text="",x=581,y=30,width=288,height=30,font=“font.ttf”,fontSize=18,align=“center”})
local function search_substitute_tap(event)
search.text=""
native.setKeyboardFocus(search)
end
search_substitute:addEventListener(“tap”,search_substitute_tap)
local function updatetext(event)
search_substitute.text=search.text
end
Runtime:addEventListener( “enterFrame”,updatetext)
I know my syntax isnt the easiest to read but i’m used to it.
anaqim
@anaqim: yep, that’s basically what I’m doing to create my “fake” input fields. Hiding a native text field that intercepts user input and passes it along to a Corona display object. 
Keep in mind that you can’t really edit this. Mobile OS’s allow you to tap and hold inside the string and jump the cursor to that location, you can also select/copy/paste and use handles to manage what’s being selected. This seems to me to not be possible if you can’t touch the physical field.
Rob
@rob - you are right, it’s not a perfect solution. But I have put some effort into finding as much of a middle ground as I can, and it’s not so terrible. There are ways of massaging things to retain maximum editability but still prettifying things. For example, you can hide the native input until the user is actively editing, then strategically place it over your OpenGL version.
Again, it’s not a full-stop replacement for native inputs, but I do look forward to making the plugin ready. I think it could prove useful.
I will say, it has been an education discovering all the peculiarities of the various native inputs (MacOS, Windows, iOS, Android, textField vs textBox, etc.) - they all behave just a little bit differently from one another.
By which I mean, kudos to the fellas and ladies at Corona Labs who manage to wrangle all these different platforms into a single SDK that pretty much operates the same on all of them. It boggles the mind. :huh:
Hi guys!
Personally I am not looking for a solution that is omnipotent by design and features, just one that works better for me.
I do look forward to Schroeders plugin though :rolleyes:
I’v just tweaked it a bit and added placeholder text as well as a moving input marker and I am happy with how it works and looks.
Mobile OS’s is of couse important but as this is my second corona app for windows and mac, i am currently more focused on that.
My first was Radiance (version 2 in the pipeline)
This second is called Companion and is a Spotify database, helper, updater and notifier.
For me, this is strictly a win32 app. It’s not meant for mobile and it gives me exactly what I am looking for.
A robust, configurable control that look and feel like the rest of the application.
At edit time, the background shows up for just the field being edited, but it’s not a whole screen of 20 to 30 ugly looking windows textboxes that mar my beautiful looking corona app.
I totally get why this can’t be supported out of the box. It would be a nightmare to support…
Thanks
Herb
A native component it is not technically part of Corona and is drawn by the OS.
Looks like Roaming Gamer has just what the doctor ordered…
https://github.com/roaminggamer/RGEasyTextField/
I will give this a try