I’m working with large values that need to be displayed as text with selected precision. IN the old realm, we used Format(value, “template”). Format doesn’t seem to exist in the iOS framework.
How should we do something like Format to get the output that we need?
EDIT - D’oh Int.ToText has the Format parameter…
That doesn’t qualify as a D’oh on your part. Format has been part of REALBasic for as long as its been around.
So much is different in IOS
look like hopes of being able to reuse large chunks of even non-UI code are now unrealistic…
I’ve also just learned that Val is gone as well. You now use NumericType.FromText(sometextValue)
But don’t try to read the text from a TextField because you’ll get an UnsupportedFormat exception. Apparently, it must be a two step process - assign the Textfield’s Text to a “Text” variable and the Double.FromText that variable. Still trying to get that one sorted.
All I need for this simple tool to do is to take some large numbers, get a multiplier value from the user, run some simple multiplication and addition on the numbers and display the results in 3 labels.
I’m also having a blast with controls jumping all over the place while I’m trying to get things laid out, but that’s a topic for a new conversation.
[code]Dim i as integer = Integer.FromText(TextField1.text)
//do some math
TextField1.text = i.ToText[/code]
I can’t disagree with this.
[quote=150720:@Tim Jones]But don’t try to read the text from a TextField because you’ll get an UnsupportedFormat exception. Apparently, it must be a two step process - assign the Textfield’s Text to a “Text” variable and the Double.FromText that variable. Still trying to get that one sorted.
[/quote]
I’m not sure why you’d be getting the exception. Could you post some sample code?
This code raises an “InvalidArgumentException” if the TextField has no text in it:
Dim i As Integer
i = Integer.FromText(TextField1.Text)Instead you have to write:
Dim i As Integer
If Not TextField1.Text.Empty Then
i = Integer.FromText(TextField.Text)
End If
Ug. That’s a pain.
Is that a bug or by design?
By design. An empty text is not a valid number.
Then maybe it should return “NaN” or 0 instead of an error?
What other changes versus Val does this bring? I constantly converted text to numbers with Val where the text would be something like “1200KB” or “12345MiB”. Val knew to ignore the textual part and gave me values of 1200 and 12345.
It will throw an exception because these are not valid numeric values.
In my best Dan Carvey Church Lady voice “well, isn’t that just special.”
That is a ROYAL UNNEEDED PAIN IN THE BACKSIDE!
I’m sorry but that is ivory tower IT type thinking… Not user friendly BASIC philosophy at work
In science and technology numbers are OFTEN exported from instrumentation with units.
Being able to convert them to a numeric value without having to parse the field is a HUGE time saver…
VAL worked the way it did because it was PRACTICAL for many of not most use cases… If this is the way the new framework is going then perhaps I made a mistake renewing until 2020…
To me stuff like this is akin to having to manage memory yourself and is a waste of time and certainly no fun…
Karen (who is very worried that Xojo will become a PIA language to use rather than a joy!)
Well, I think at this point I’ll just right an extends method. That will solve the issue for me, at least.
Not doing so is a great opportunity for silently doing something really wrong.
VAL would gladly give you 0 for val"(foo") and your calculation then proceeded to turn out erroneous results.
We have a number of bug reports about how Xojo can’t do proper math for this sort of reason.
One of the new framework design principles is to not fail silently, and returning something indistinguishable from a potentially proper value (like 0) should not represent an error. Trying to convert a non-number to a number and sometimes getting it right but sometimes getting it wrong- and never saying anything- can be a recipe for disaster.
A variation of a real world example I was helping someone with: just glance at “abc12345abc”, “abc12345”, “12345abc”- what do you think Val would return for those? Most people get it wrong particularly if they haven’t used it a lot. It’s not a good thing.
The perspective taken is that the Xojo developer is in a much better place of understanding to know when/how their particular input should be sanitized or transformed than we are. If something isn’t the expected type, we should say so.
[quote=150986:@Karen Atkocius]That is a ROYAL UNNEEDED PAIN IN THE BACKSIDE!
I’m sorry but that is ivory tower IT type thinking… Not user friendly BASIC philosophy at work
In science and technology numbers are OFTEN exported from instrumentation with units.
Being able to convert them to a numeric value without having to parse the field is a HUGE time saver…
VAL worked the way it did because it was PRACTICAL for many of not most use cases… If this is the way the new framework is going then perhaps I made a mistake renewing until 2020…
To me stuff like this is akin to having to manage memory yourself and is a waste of time and certainly no fun…
Karen (who is very worried that Xojo will become a PIA language to use rather than a joy!)[/quote]
I understand what Xojo is trying to do : avoid implicit conversions that while convenient, can be source of silent bugs. The problem with returning zero when a text field contains nothing is that in effect, nothing and zero are not at all the same thing. If I forget to put a number in my text variable and use good’ol Val, I get zero and go my merry way without ever realize my mistake.
That said, I have added a lot of little things into a module during beta to wrap the new framework for comfort. Nothing prevents you from creating a Val method that behaves as it has always done, returning zero for “” or “whatever”.
Devil’s Advocate here, but what is the purpose of Xojo if we need to rewrite it to use it as we always have or learn a new API that feels like a combination of Java and Obj-C (and I agree with Karen’s comment)?
As mentioned in other conversations, this kind of change very quickly moves Xojo-based development away from RAD and closer to the other existing language solutions.
[quote=150999:@Norman Palardy]Not doing so is a great opportunity for silently doing something really wrong.
VAL would gladly give you 0 for val"(foo") and your calculation then proceeded to turn out erroneous results.[/quote]
I could live with an exception for “” or “ABC123” but there is not point to throwing an error for “123.5mg”
(you - Xojo inc)… And If we care Just prvide a check function (Text.IsFullyNumeric) for teh times it matters to us.
You really are making Xojo too tedious and getting away from the STRENGTHS of BASIC that made so many of us fall in love with REALBasic compared to other languages.
My point on practical vs purist stands and I am 100% positive this purist approach will make Xojo less popular as it makes writing code feel more like a slog through mud than the RELATIVE joy it has been.
I feel you guys are too close to it to realize the downside of the approach you are taking
“abc12345abc” and “abc12345” can be a exception.
“12345abc” should return 12345.
The above is totally logical AND intuitive… (Looks for leading numbers… converts them to number, if nobe found then exception)
And anybody who can’t understand that EVEN with reading the documentation (which most would not need to) quite frankly would not be capable of coding much of anything…
In any case you it makes sense to make life harder for all of us because a few people can’t understand something a LOT simpler than operator precedence, never mind inheritance?