SC7. Decimal type fields are unusable for data entry.
To Reproduce:
Create a form.
Add a Decimal value field that can be positive or negative, default 6 digits of precision.
Run it.
Try to enter the following values w/o becoming angry: -3, 3.14, 3, -1, -147.2823499
I have found no workaround. Turn off auto-fill and it still fills with zeroes.
I haven’t tried this on SC8.
Hello,
Do you have the correct decimal separator set under your connection advanced properties?
regards,
Bernhard
[QUOTE=bartho;27583]Hello,
Do you have the correct decimal separator set under your connection advanced properties?
regards,
Bernhard[/QUOTE]
Thanks Bernard.
Define “correct”. It’s set to a period (dot). The typical USA separator. I assumed this would be handled by the “Regional Settings” option, which is the only option enabled. If not, make that another bug report.
This could be an “expectations” issue, but floating point number entry in ScriptCase does not behave like floating point number entry on any other user interface on this planet (software or hardware calculators, any spreadsheet ever, any VCR, camera, phone, etc). Nobody else does it the way ScriptCase does it because there is no conceivable reason to make it so difficult and broken.
If a user hits the keys ‘-’, ‘3’, ‘.’, and ‘1’, the field should have “-3.1” in the field.
I have not found a way to make SC’s “decimal” fields do this. (Decimal means “Base 10 number”, by the way - as opposed to hexadecimal for Base 16, octal for Base 8, binary for Base 2, etc: not floating point or double-precision, which is what SC’s decimal type represents)
I’m tempted to change all of these to “text” fields that accept only ‘-’, ‘.’, and [0-9].
TRY IT. It’s extremely easy to test. Create a “decimal” field. Try to enter “-3.1”. Now, imagine that you have a form with dozens of floating point numbers to enter. My testers are not happy at all.
In decimal precision put the number 6. For this number: -147.2823499 you will need 7 to be the decimal precision.
Set auto complete with zero’s to yes.
Try that, validation image shows as accepted value.
The only thing is, is that it adds 5 0’s to the end of this number -3.1 like this -3.100000 but that’s still the same value.
The weird problems with decimals disappeared for me when I disabled “digital grouping”:
This lot allows a 5 “character” positive number including decimal point: e.g. 99.99
I have digit grouping disabled.
Interesting: with zero-padding enabled, the number does not get zero-padded, and if I first delete the contents of the field, then I can enter a floating-point number in a normal and sane manner. If you tab to the field however, which selects all the previous text, entering “-3.1” puts “3.1” in the field. The ‘-’ is dropped.
I am assuming that a checked box means that the feature is enabled. It doesn’t behave that way.
I suspect all three of these behaviors are new bugs, all by themselves.
Bernhard, I think there are enough bugs in just this one field type for a single report. If it were my team, we’d review every line of related code based on how this behaves, cuz wow, but I have my own projects.
Hello,
Issue reported to our bugs team.
regards,
Bernhard Bernsmann
is there any progress on sc9? I am having this problem on entering decimal digits as described .