I'm binding a UITextView to a field of data type float, and it seems that the binding mechanism is being over-vigilant in validating my data such that I cannot actually enter floating point numbers.
Specifically, if I type "7" in my UITextView, the float field in the data model updates. If I paste "7.2" in the text view, it also updates. But if I type "7." (on the way to typing "7.2"), the binding fails with error:
MvxBind:Error:365.27 SetValue failed with exception - FormatException: Invalid format.
This is arguably correct, since "7." isn't a valid numeric string.
But it also discards the decimal point, and so I can't enter my number. It just leaves "7" in the text view. The weird thing is that this is ONLY affecting the decimal point/period character. If I type "7X", it doesn't bind, but it does let me type the X. What's going on here?
Just may be try to bind to string value and make a little manually in code string<=>float conversions? Also this should be much better way on monotouch specifically since based on the common .net functions rather than on the UI implementation.
Related
Reading the documentation and this answer, I see that I can initialize a Unicode character in either of the following ways:
let narrowNonBreakingSpace: Character = "\u{202f}"
let narrowNonBreakingSpace = "\u{202f}"
As I understand, the second one would actually be a String. And unlike Java, both of them use double quotes (and not single quotes for characters). I've seen several examples, though, where the second form (without Character) is used even though the variable is only holding a single character. Is that people just being lazy or forgetting to write Character? Or does Swift take care of all the details and I don't need to bother with it? If I know I have a constant that contains only a single Unicode value, should I always use Character?
When a type isn't specified, Swift will create a String instance out of a string literal when creating a variable or constant, no matter the length. Since Strings are so prevalent in Swift and Cocoa/Foundation methods, you should just use that unless you have a specific need for a Character—otherwise you'll just need to convert to String every time you need to use it.
The Swift compiler will infer the type of the string to actually be character in the second case. Adding : Character is therefor not really needed. In this case I would add it though because it's easy to mistakenly assume that this Character is a String and another developer might try to treat it as such. However, the compiler would throw errors because of that since it inferred the type of this String to not be a String but a Character.
So in my opinion adding Character is not a matter of being lazy or forgetting it, it's a matter of trusting the compiler to correctly infer the type of this constant en to rely on the compiler throwing the correct error whenever I try to use this constant wrong.
Swift's compiler basically takes care of all the details and it doesn't really matter if you add Character, the compiler will (should) take care of it.
I'm using Min/Max Beanvalidation. Here is an example:
#Min(value = 100, message="too low")
#Max(value = 1000, message="too high")
private Integer example;
If i enter 99 i get the correct message "too low". If i enter 1001 i also get the correct message "too high". If i enter a very high number e.g. 10000000000 i get a generic message which i found out is this one: javax.faces.converter.BigIntegerConverter.BIGINTEGER={2}. So i suspect that if the user enters a number which is larger then the actual field type, he will get another message.
This is actually not what i want to achieve. I always want to show the user "too high". Is there a way to achieve this?
There are really two things going on, conversion and validation. In a first step JSF needs to take your string input and convert it to a number. This is where you get the error. Your value cannot be converted to an Integer. If conversions works, JSF populates your model and that's where validation kicks in. If validation then fails you get the defined Bean Validation messages. So what can you do:
Configure the JSF message for javax.faces.converter.BigIntegerConverter.BIGINTEGER={2} to be more descriptive
Change the datatype, for example use BigInteger. In this case the conversion from string to number will work
Use string in the bean and validate the string. You probably need then to convert to a number at a different point though, but that depends on you use case.
The maximum for Integer in java is 2^31 which is just over 2.1 billion. The input you used, 10 billion, is then beyond the maximum of an integer and would overflow the field, so it is not a valid given the field type, regardless of any validation you may have in place. you could switch the field type to be a BigInteger, then override the default validation messages to fit your needs, but that may be overkill given the purpose of your question. You can also have custom messages
Why not just limit the amount of characters in the inputfield in the frontend, for example
<h:inputText maxlength="4"/>
I'd guess it's possible to bypass if you really want, but I would'nt worry too much about the usability for someone hacking the site :-)
I was wondering if there is a component like the 'edit', but just for numbers so I can use the .value function in my code.
My textbook says I must make a program, that when the user enters a number and clicks the execute button, the results of the functions must be determined.
The functions are: Trunc, round, frac, sqr and sqrt.
I have to enter the value into, what looks like an 'edit', but whenever I use the .value in my code, it gives me an error saying :Undeclared identifier: 'value'. Although it works when I use a 'SpinEdit'.
Forgive me for being really thick, I do have a severe chest and sinus infection with a fairly bad fever, so my mind is somewhere else at the moment.
Thanks!
Oh, and by the way, I have also used the 'MaskEdit' component but it still gives me the same error
For an edit control there is no property named Value, which is what the compiler is telling your. For an edit control the property you need is Text. That's a string containing the contents of the edit control. You'll need to use StrToFloat or TryStrToFloat to convert to a real type.
You can use a masked edit if you like, and validate the input on entry. The TMaskEdit control derives from TCustomEdit, and again the property used for accessing its content is Text and of type string.
Personally I don't like that because I don't think it gives the clearest feedback to users. It's also hard to write a mask for a general floating point value. Myself, I would validate at the point where the program needs to convert from string to real.
Well, since you asked if there is an edit like component for that, I use TMS AdvEdit. It does a very decent job handling integers and floats. If you can afford it, it's really useful.
It has .FloatValue and .IntValue properties for reading and writing the value, and an EditType that specifies what kind of input is accepted.
I have stringgrid on delphi form and i am trying to divide values of one cell with value of another cell in another column.
But the problem is, stringgrid cells are populated with different types of numbers, so I am getting ConvertErrors.
For example the numbers in cells can look like
0.37 or 34 or 0.0013 or 0.00 or 0.35 or 30.65 or 45.9108 or 0.0307 or 6854.93.
In another words I never know is it going to be real, float, integer or any other kind of type in those cells.
I have looked everywhere on internet but no luck. Anyone any ideas. By the way I am not exactly Delphi expert. Thanks.
For each string, convert it first to a float value using StrToFloat function in SysUtils.pas . This should allow for any numerical type to be dealt with (unless you have something unusual like complex numbers). As you have some zero values in your list above you should also ensure that you check for divide by zero conditions as this will also potentially throw an exception.
SysUtils has many functions such as TryStrToFloat, TryStrToInt, TryStrToInt64 etc for this purpose. These functions accept a reference parameter (var parameter) for returning the converted value and function itself returns true if the conversion is successful.
If you are sure that the string has a valid number then you can check the input string to see if it has a decimal point before deciding which function to use.
Treat all the numbers as float. Use StrToFloat, divide the numbers, and then convert the result back to string with FloatToStr. If the result is an integer, no decimal point would be produced.
I'm having a strange problem that is affecting at least some of my international users of my Delphi 6 application. Here's the scenario:
My program requests status reports periodically from an external device that acts as an HTTP server.
The device sends back the status report as a response document that has a series fields delimited with the pipe character in name value pair format (e.g. - field1=-0.437).
I split the report string into the fields and then again to get each field name and numeric value.
I use StrToFloat() to convert the floating point field values in string format and assign the result of that function to a Variant variable.
This works fine on most PCs, but some of my international users are getting EConvertError's when I try to use StrToFloat() on the numeric values. Here's a concrete example of an error message from my logs:
EConvertError: '-0.685' is not a valid floating point value
As you can see -0.685 is a valid floating point number, yet I am getting the EConvertError Exception. Normally I would expect to see a comma where the decimal point is, or some other locale specific punctuation problem, but the number appears fine in this case. Also, to the best of my knowledge the external device does not even have the option to set the character set.
So what subtle nuance about Delphi 6 and international character sets might be causing this problem, perhaps related to the user's Windows XP/Win7 character settings? Note, I use standard Delphi 6 "string" cast strings throughout my program so I don't see how a multi-byte character set issue could be the root cause. Has anyone had this problem and knows what to do about it?
Your remote user's machine is expecting , for the decimal separator. When it encounters . the EConvertError exception is raised. On a machine which expects , as the decimal separator (e.g. most European and South American countries) -0.685 is indeed not a valid floating point value.
Normally I would expect to see a comma where the decimal point is, or some other locale specific punctuation problem, but the number appears fine in this case.
Your current problem is just the flip-side of the above issue. Normally, because your locale uses . as the separator, you are accustomed to seeing problems when data with , is used instead. Put yourselves in the position of somebody from a country which uses , as a separator. For them, they will be accustomed to seeing exceptions when data with . is used.
You could solve the problem by normalising the input to use the same decimal separator as the the machine locale. On a modern Delphi you could solve the problem by use the StrToFloat overload that receives a TFormatSettings parameter and explicitly specify that . is to be used as the decimal separator for this conversion. Unfortunately that facility is not available in Delphi 6.
I faced this issue for Belgian users. I also had to manually replace the '.' or ',' in the input data.
Also, if you are inserting the data into the database (sql) then, you will have to replace the ',' with '.' during insertion of the data into the database.