While all my imports of TSV and CSV files seem to work well, I am getting error messages when I try to enter or edit 2-digit decimals manually in a floating point numbers field.
It does not matter if I try German format “123,45” or U.S. format “123.45”.
(I had entered the shown pattern manually.)
P.S. It would be nice if the entry of Output Patterns would accommodate the System’s number formats. So I would like it if I would not have to enter a pattern in U.S. format ("#.## €") to get my output in the systems German number settings ("#,## €").
There are more oddities when I try to calculate the content of a floating point number field (output pattern “#.##”) from a value in a text field.
If you are feeling ambitious, you should be able to patch this to fix it. The problem is line 68 of DATAVALIDATIONALERT in _DatabaseLib. Here is the current line:
if (_VALUE_ regexmatch {^[+-]?\d?+(\}+info("decimalseparator")+{)?(\d+)?[ ]*([Ee][+-]?\d+)?$}) = false()
The correct line should be:
if (_VALUE_ regexmatch {^[+-]?\d*(\}+info("decimalseparator")+{)?(\d+)?[ ]*([Ee][+-]?\d+)?$}) = false()
I made a change in the last beta to allow numbers without a digit in front of the decimal point (for example .45), and I screwed it up for numbers with more than one digit in front of the decimal point. Of course this will be fixed in the next beta.
Two reasons this won’t be done:
As for the pattern menu problem, looks like that has probably been a bug from day one. Should be easy to fix. For now, if you click on another field and then click back, the menu will fix itself.
I re-checked those calculations in Panorama 10.1.2 (2854). Here the 1st value is calculated to the same result; the 2nd value is calculated to the result 12345.
The val( function does not seem to recognise decimal numbers; it seems to be calculating integer numbers only.
OK, data entry in the floating point field is working with this correction!
Here the 1st value is calculated to the same result; the 2nd value is calculated to the result 12345.
Here? What 1st and second values? I don’t see any values.
I think by “decimal numbers” you mean numbers with a fractional component? As far as I can see the val( functions works fine. Please elaborate.
Ok, I think I figured out what you mean. Oh my gosh, what a can of worms. It appears that the val( function hasn’t worked for numbers with a fractional component since February 2017 in countries that use comma as a decimal point.
Ok, I have now fixed this, and I have also made a major change to the val( function that allows the decimal point to be specified explicitly. I would appreciate feedback on whether everyone thinks I have done this in an appropriate manner – if not, now is the best time to make adjustments.
Never mind. I figured it out. But I would rather not do that on every computer who is in our test.
I am ambitious enough but not knowledgeable enough to change the code as you suggested. I found the procedure and substituted the corrected code, but when I try to save it, the message says the disk is locked so I cannot save it. Is this something you can give me some help to fix?
Looks good for me.
If you’ve done it on one you should be able to just copy the patched application to the other computers.
Yesterday it took several hours to publish the b6 release, partly because the upload speeds here are not very good. So it’s not very practical for me to upload a new version just for this. But since it was patchable, I wanted to offer the patch, even though it is a bit awkward.
Of course, no need for you to publish another version. I didn’t realize that I could just copy the application.