You could take a look at the following, where there are a couple of solutions. The basic work has been done but a few amendments needed, they seem to work quite well.
, Content - English Overview, Maths, Check
Two that may help are :
IsAlpha&IsNumeric.pb and Numeric_Check.pb
I'm not sure about the detail on your application but presume you are storing results into a database and I don't want to teach you to suck eggs. But this may help someone, sometime.
From my experience for any number handling I always convert results to Integers. (or Long etc depending on the language etc) I'll usually do the maths using decimal numbers, store the numbers used and save the calculated result into a table as Integers. I will then string handle the decimal point for reports and will avoid the problems and pain from results truncated from 12 to 16 decimal places that can result in different totals when adding many numbers.
Presumably each individual field will have a specific number of decimals, two or three so it is easy enough to write a function to display the actual decimal resulting number correctly. Adding up Float or Double numbers can often produce different results, which, say in a financial package just isn't acceptable. Totals on invoices or statements just cannot be a penny out! Integer calculations will avoid this problem. Adding integers and then placing the decimal point in the total will always show the same result.
Regards, C87
If it's falling over......just remember the computer is never wrong!
C87 wrote:You could take a look at the following, where there are a couple of solutions. The basic work has been done but a few amendments needed, they seem to work quite well.
, Content - English Overview, Maths, Check
Two that may help are :
IsAlpha&IsNumeric.pb and Numeric_Check.pb
[/quote]
Thanks for your response. I did look at these together with numerous similar solutions, but what I was after was a solution where it was impossible to enter a non-legitimate character. I wasn't particularly looking for a warning that a non-legitimate character was being entered, because the code would prevent the entry. I think the code I have posted does that. For my own use, the size of numbers I am looking at will be in the range 0.0001 to 999, with a requirement for negative values in the same range, and they will be used in simple formulae.
[quote]
I'm not sure about the detail on your application but presume you are storing results into a database and I don't want to teach you to suck eggs. But this may help someone, sometime.
From my experience for any number handling I always convert results to Integers. (or Long etc depending on the language etc) I'll usually do the maths using decimal numbers, store the numbers used and save the calculated result into a table as Integers. I will then string handle the decimal point for reports and will avoid the problems and pain from results truncated from 12 to 16 decimal places that can result in different totals when adding many numbers.
Presumably each individual field will have a specific number of decimals, two or three so it is easy enough to write a function to display the actual decimal resulting number correctly. Adding up Float or Double numbers can often produce different results, which, say in a financial package just isn't acceptable. Totals on invoices or statements just cannot be a penny out! Integer calculations will avoid this problem. Adding integers and then placing the decimal point in the total will always show the same result.
Regards, C87
[/quote]
No it is not my intention to store results in a database, although this would be an alternative method. What I am considering is a grid of StringGadgets where entries would be made and the entries would then be transferred to arrays and computation then takes place with the final output being in columns in a ListGadget. The calculations do not need a great level of accuracy (in the old days, when I first started out in 1960, the computations were by sliderule and this is the sort of level of accuracy needed).
However, where greater accuracy is required I can see the sense in the method you suggest. I'm not likely to need it myself, but others might. Perhaps you could provide some code to demonstrate. I would certainly be interested as I am sure others would be also.