My 2 cents as a new Corona developer: I don’t see anything on the roadmap related to fixing the Windows simulator issue, and it concerns me.
I’d love to use Corona for both business apps and games, but I’m in the same boat as some of the others above (no Mac at work). Building and deploying to the device after every code change is obviously not a viable option. [import]uid: 207504 topic_id: 24285 reply_id: 140337[/import]
@curjo, Just to let you know that turning off the Autocapitalization on the Email keyboard was a quick fix and should be available in next daily build (1018 and higher).
-Tom [import]uid: 7559 topic_id: 24285 reply_id: 141014[/import]
Great – many thanks! [import]uid: 101071 topic_id: 24285 reply_id: 141029[/import]
string.upper/lower/len etc does not work with swedish åÅäÄöÖ, not sure if corona is aware of that. Found out that the hard way… [import]uid: 13560 topic_id: 24285 reply_id: 141032[/import]
This is a problem for me too. I need to allow users to enter email addresses, so I’m using the “email” keyboard, but it has caps on by default. I would think it’s rare to want to capitalize your email addresses – and in my case, it’s a real problem. Any workaround? Can you simulate a “shift-key-pressed” event in the textListener function (event.phase == “began”)?
Please let me know if/how others have gotten around this. Do I have to use a 3rd-party keyboard library? Ideally, there would be an optional flag to control the caps state when invoking any keyboard. Also, how about a “.com” key? Thanks! [import]uid: 101071 topic_id: 24285 reply_id: 140472[/import]
@curjo, goto http://feedback.coronalabs.com and enter the request there then vote for it. I’m pretty sure it’s something we are looking at, but putting it there and getting some votes on it will help make sure it gets on the radar.
[import]uid: 199310 topic_id: 24285 reply_id: 140484[/import]
If the problem is the user enters the address in all caps, why can’t you just convert the text back to lowercase afterwards?
local text = string.lower( textField.text ) The keyboards used in native.newTextField and native.newTextBox are the ones provided by the OS so any feature requests would need to be properties supported by the OS.
You can create your own text input and keyboard entirely in Corona and then you would have full control of what happens. [import]uid: 7559 topic_id: 24285 reply_id: 140538[/import]
Hi Tom:
Thanks for the reply. The problem is not that I want the user to enter in all caps, I want to allow them to enter in lower case (which is how most email addresses are typed) – or in mixed case, if they prefer. The problem is that, while I could force the case to upper or lower after they enter it, this would mean that I’m not storing what they entered (which I need to do). I’d like to simply have it start out defaulted to lower case (i.e., no auto-capitalization) – as this is by far the most typical way addresses will be entered.
Regarding the native OS, there is a property that should be settable to define capitalization. Here is an excerpt from the reference (I’m wanting “UITextAutocapitalizationTypeNone”):
UITextAutocapitalizationType
The auto-capitalization behavior of a text-based view.
typedef enum {
UITextAutocapitalizationTypeNone,
UITextAutocapitalizationTypeWords,
UITextAutocapitalizationTypeSentences,
UITextAutocapitalizationTypeAllCharacters,
} UITextAutocapitalizationType; Constants
UITextAutocapitalizationTypeNone
Do not capitalize any text automatically.
Available in iOS 2.0 and later.
Declared in UITextInputTraits.h.
UITextAutocapitalizationTypeWords
Capitalize the first letter of each word automatically.
Available in iOS 2.0 and later.
Declared in UITextInputTraits.h.
UITextAutocapitalizationTypeSentences
Capitalize the first letter of each sentence automatically.
Available in iOS 2.0 and later.
Declared in UITextInputTraits.h.
UITextAutocapitalizationTypeAllCharacters
Capitalize all characters automatically.
Available in iOS 2.0 and later.
Declared in UITextInputTraits.h. [import]uid: 101071 topic_id: 24285 reply_id: 140546[/import]
You can create your own text input and keyboard entirely in Corona and then you would have full control of what happens.
This is certainly possible and I did entertain the idea for a couple minutes. It might even be doable for entering text into one or maybe two fields. My contention was that Corona is being touted as a viable platform for creating non-gaming apps which is simply not true when there is such limited support for something so basic as entering text via the native keyboard. I just can’t see a serious business app requiring the user to enter text into multiple fields using a Corona created, app-specific keyboard. I don’t think Apple users would want to give up the iOS keyboard and it’s worse on Android where many of us have picked a specific 3rd party keyboard because we find it easier to use.
Personally, I’m still hoping Corona builds a usable Windows simulator and does something to fix the TextInput issue. I seem to be in the minority, though, because there didn’t seem to be much support for either according to votes on the Future Feature page. This seems to reinforce the notions that:
a) Corona is mainly used to create games and,
b) Corona is used mainly by Apple developers
At the moment, I’m trying out Flash/AIR with Starling/Feathers. Text support isn’t quite as good as with Flex but it’s vastly better than Corona and the scrolling speed and animations are very, very smooth. The windows mobile simulator seems to be pretty good and on-device debugging works as expected. The biggest drawback is the load times because adding AIR to the app makes it very large. Not adding AIR means it has to already be on the user’s device.
[import]uid: 156068 topic_id: 24285 reply_id: 140582[/import]
@maxapps, can you explain what you mean by this:
“My contention was that Corona is being touted as a viable platform for creating non-gaming apps which is simply not true when there is such limited support for something so basic as entering text via the native keyboard.”
Is this just a matter of giving more access to keyboard properties? [import]uid: 26 topic_id: 24285 reply_id: 140674[/import]
Strange, string.len works with norwegian æ,ø,å… at least on the iphone device (haven´t tested the simulator though). [import]uid: 141323 topic_id: 24285 reply_id: 141513[/import]
It works but does not return the right value, I discovered this while working with textfields. I found a utf8 library that takes care of string.len() but not string.upper/lower().
If you would create text edit app and would want to know the character count len() would not return the correct count, however bytewise it is correct.
Run this.
local txt1 = "åäöÅÄÖ" -- len return 12, string.upper/lower() does not work.
local txt2 = "abcABC" -- len return 6, string.upper/lower() does work.
local lower = display.newText("txt1 (åäöÅÄÖ) to Lower: "..string.lower(txt1), 30, 150, 260, 0, "Helvetica", 16)
local upper = display.newText("txt2 (abcABC) to Upper "..string.upper(txt2), 30, 190, 260, 0, "Helvetica", 16)
local len = display.newText("txt1 Len: "..string.len(txt1).."\ntxt2 Len: "..string.len(txt2), 30, 230, 260, 0, "Helvetica", 16)
Utf8 functions from the lib that fix the len() issue.
[code]
function utf8charbytes (s, i)
– argument defaults
i = i or 1
local c = string.byte(s, i)
– determine bytes needed for character, based on RFC 3629
if c > 0 and c <= 127 then
– UTF8-1
return 1
elseif c >= 194 and c <= 223 then
– UTF8-2
local c2 = string.byte(s, i + 1)
return 2
elseif c >= 224 and c <= 239 then
– UTF8-3
local c2 = s:byte(i + 1)
local c3 = s:byte(i + 2)
return 3
elseif c >= 240 and c <= 244 then
– UTF8-4
local c2 = s:byte(i + 1)
local c3 = s:byte(i + 2)
local c4 = s:byte(i + 3)
return 4
end
end
– returns the number of characters in a UTF-8 string
function utf8len (s)
local pos = 1
local bytes = string.len(s)
local len = 0
while pos <= bytes and len ~= chars do
local c = string.byte(s,pos)
len = len + 1
pos = pos + utf8charbytes(s, pos)
end
if chars ~= nil then
return pos - 1
end
return len
end
[/code] [import]uid: 13560 topic_id: 24285 reply_id: 141530[/import]
@curjo, Just to let you know that turning off the Autocapitalization on the Email keyboard was a quick fix and should be available in next daily build (1018 and higher).
-Tom [import]uid: 7559 topic_id: 24285 reply_id: 141014[/import]
Great – many thanks! [import]uid: 101071 topic_id: 24285 reply_id: 141029[/import]
string.upper/lower/len etc does not work with swedish åÅäÄöÖ, not sure if corona is aware of that. Found out that the hard way… [import]uid: 13560 topic_id: 24285 reply_id: 141032[/import]
Is there a plan in place to support keyboard options. For example on iOS devices you can set in your settings the ability to
* Auto-Capitalization
* Auto-Correction
* Check Spelling
But in your app, you can modify the default settings of the app. For example, if you don’t want the app to check for spelling or to auto-correct, etc.
The reason I ask is because I am building a spelling app and it is useless to use your keyboard if it continually pops up spelling suggestions.
I have written a keyboard from scratch but there are so many issues like supporting different languages, supporting right-to-left languages etc that I’d rather use the native keyboards if possible instead of doing all the language support.
[import]uid: 138352 topic_id: 24285 reply_id: 141774[/import]
The best way to bump up the feature is go to our feedback page and add/vote on the feature.
http://feedback.coronalabs.com/forums/188732-corona-sdk-feature-requests-feedback [import]uid: 7559 topic_id: 24285 reply_id: 141813[/import]
I solved the upper/lower case issue with mapping, writing a routine was just to much hazzle atm. I only need to map 6 characters (åäöÅÄÖ) so it was easy and fast. [import]uid: 13560 topic_id: 24285 reply_id: 141842[/import]
Actually, you are right in a way:
for l=1,3 do
print(string.sub("abc",l,l))
end prints:
a
b
c
but using
for l=1,3 do
print(string.sub("æøå",l,l))
end result in an error:
2013-02-06 12:50:19.493 Corona Simulator[19598:f07] Generic error:
2013-02-06 12:50:19.493 Corona Simulator[19598:f07] NSInvalidArgumentException: *** -[__NSArrayM insertObject:atIndex:]: object cannot be nil
(plus alot of garbage output)
But, assuming this is a character coding scheme in which ø is actually two characters
(like unicode o/slash/):
for l=1,3 do
print(string.sub("æøå",l\*2-1,l\*2))
end actually prints:
æ
ø
å
So it seems like the length of special characters in some instances are 2 bytes. When this happends, trying to get a substring which is only half the character (string.sub(“æ”,1,1)) results in a simulator crash. If you always treat the character as two bytes, it works with minor problems…
[import]uid: 141323 topic_id: 24285 reply_id: 141847[/import]
Strange, string.len works with norwegian æ,ø,å… at least on the iphone device (haven´t tested the simulator though). [import]uid: 141323 topic_id: 24285 reply_id: 141513[/import]