LWUIT textfield - textfield

if method setMaxSize(1) is called, tactile keypad only inputs first character .e.g. can only write A in "ABC or D in "DEF" etc any ideas on how to solve this

Interesting. I haven't tried this myself but I can see why this would fail.
I doubt whether there is a simple solution for this other that overriding the text field input and implementing the single character behavior yourself. Just set the max length to 2 and override the insertChar method by invoking super.setText() with the given char.

Related

wxStaticText inconsistently displays 'degree' character

In the same application I have two different instances of wxStaticText. Each displays an angular value expressed in degrees. I've tested both instances for font name and font encoding. They are the same for both. I've tested that both strings passed to SetLabel() are using the same character value, decimal 176. Yet one displays the 'degree' character (small circle, up high) as expected and the other instead displays an odd character I'm not familiar with. How can this be? Is there some other property of wxStaticText I need to test?
I can't explain what you're seeing because obviously two identical controls must behave in the same way, but I can tell you that using decimal 176 is not a good way to encode the degree sign, unless you explicitly use wxConvISO8859_1 to create the corresponding wxString.
It is better to use wxString::FromUTF8("\xc2\xb0") instead or, preferably, make sure that your source files are UTF-8 encoded and just use wxString::FromUTF8("°").
Arghhhh! Found it. I was assuming SetLabel() was wxStaticText::SetLabel(), inherited from the wxWindow base class. It's not. We have a wrapper class of our own around wxStaticText that I was not aware of. It's the wrapper class that is bollixing the string value.
Moral: When debugging unfamiliar code, don't make assumptions, step ALL THE WAY in.

Why do I use "parse"

What is the reasoning for parsing an integer? For instance, Integer.Parse('variable'.text)
I see this a lot and while manipulating data for a calculator I am building I found that Val('variable'.text) was all I need to use "numeric" values.
So, my question is how does Integer.Parse() help me with regards to calculators?
Thanks!
I found that "Val('variable'.text)" was all I need
If that's the case then go ahead and use Val(). But be aware that it behaves differently than .Parse() (or, often preferably, .TryParse()) methods.
For example, what do you want to do if the user inputs "123 isn't 456"? Val() will (I think) return:
123 As Double
Or how about the input "123 456"? That would be:
123456 As Double
Do you want it to be a Double? Do you want it to throw an error because it's not purely numeric? Something else? The behavior you want should be reflected in the code you write. Use Val() for one set of behaviors, .Parse() for another.

How to check if text in a UITextField matches a specific pattern?

I have a UITextField and I need to check, as the user types, if the text they have entered in the textfield so far matches a specific pattern.
More specifically, I need the text to match the pattern ####-##-## where # is any digit 0-9 and - is a dash (note that this is NOT a phone number or email). For example, the entry 1990-12-09 matches, 1990:12:09 does not match and 1990-12 DOES match because it has not yet violated the pattern (even though the text does not yet completely match the pattern).
How should I approach this? Ideally I would not have to hard code in a series of if statements .
The difficulty is that I want to check if the text in the textfield matches this pattern, as the user types. I don't want to just check it at the end.
I'm thinking that regular expressions are probably the way, but I'm not experienced enough at them to know if they hold the solution.
You could set the keyboard type to myTextField.keyboardType = UIKeyboardTypeNumberPad that why you are limiting the type of input.
Then this post should help answer your formatting question: UITextField format in xx-xx-xxx

Quick vocab definition (Objective-C)

I reread the explanation a couple of times, but I still don't understand what these are. Can someone explain to me what an argument and a format string are?
I'll answer before this question gets closed or downvoted too severely for not being specific or having much detail:
Format strings are used for passing 1-or-more arguments to compose a NSString object.
Check out this useful Apple documentation on String format specifiers.
Arguments are the parameters passed into a method or function.
And if you are talking about some compiler errors, such as the "format not a string literal and no format arguments" error you might see when trying to log stuff via NSLog, check out the answers to this very related question.
An argument is a variable value that you pass to something else, generally a method. In plain English, if you were to say "go run around the block 30 times", 30 would be the argument. Depending on your method, maybe "block" and "run" would be arguments as well, where you could also say "go walk around the house 10 times".
A format string is a string that describes how to format a series of arguments. These generally take the form of a string that has certain placeholders in it where the arguments will be shown in the result.

Objective-C: How to use both "." and "," as a decimal separator or at least convert one to another on-the-fly

I have an instance of NSTextField, e.g. someTextField, for which I will use the number formatter to limit the input to numbers only.
The problem comes with the localization combined with the specific keyboard layouts used.
I would like to allow both the, say, American and European users to enter their localized decimal separators. As you all know, in the USA that would be . and for the good part of Europe that would be , (and similar with the thousands separator, etc. but let's put that to the side for now).
So I wrote the following task:
[numberFormatter setLocale:[NSLocale currentLocale]]; for the instance of the NSNumberFormatter.
Problems occurs when the user who has , set as a decimal separator AND US keyboard layout switched on (fairly common here in Europe) presses the decimal separator key on the numeric keyboard. With the US keyboard layout on, that would give him the . as the decimal separator but at the same time it'll be ignored in the someTextField because of the localized settings system-wide. So, if you want to type 1/2 using numeric keyboard only, you'll type 0.5 (US keyboard layout) in the text field and it would be read by the system as 0 because it recognizes only , as decimal separator. This is how the program currently is working and I would like to improve it in this regard.
I would like to allow user to type in the . in the someTextField and for the system to recognize it as a decimal separator just like it would ,. This kind of behavior can be seen in Apple's own Calculator application. If you type . on the numeric keyboard it'll appear as , immediately on the screen (for all conditions as described previously).
Question is: is it possible for me to achieve this using an instance of NSNumberFormatter? If not, is it possible to set on-the-fly conversion of the numerical keyboard decimal separator key output to the decimal separator set system-wide? Or perhaps you have some other suggestions?
Thanks.
I don't have a specific answer to your question, but I'd say the right approach is not to muck about with the NSNumberFormatter at all and concentrate on trying to change the characters generated by the keyboard.
The default locale for number formatters is usually the system's default locale as set by the user in the internationalization settings. If you change that behaviour programmatically for UI elements, you are effectively telling the user "I know better than you how you want to input numbers". Arrogance of that sort on the part of the developer never gets them good marks with respect to UI design.
In fact, you could apply the same argument to remapping the dot button on the numeric keypad. How do you know that the user hasn't set US keyboard layout because it allows them to get a dot from that key? Maybe they consider it more important to be able to type the thousands separator from the keypad than the decimal separator. I'm not saying you shouldn't implement your feature, just make sure that the user has control over when it is enabled or disabled.
Anyway, you probably want to override the keyDown event on the control. More info here.
Take a look at the UITextFieldDelegate protocol. It allows your textfield to ask its delegate if it should accept a character which the user just typed. The apropriate method would be textField:shouldChangeCharactersInRange:replacementString. If the character in question is , or . just let the delegate append the properly localized decimal separator "manually" and return NO.
I'm not quite sure if this will work if the text field is set to number mode, maybe the input is being filtered before the delegate method is called - leading to the method not being called if the "wrong" separator has been filtered out previously. If so, you might want to consider leaving the text field in alphanumerical mode and use the delegate method again to filter out anything that is not numbers or separators. However, in this case you should make sure the user is not allowed to type more then one decimal separator - either ignore the surplus ones or remove the first one and accept the new one.