Changing the way number field with calculator are handled
Description
Environment
Activity
Martin Schönbeck May 8, 2021 at 7:00 PM
Hi @Carlos Ruiz,
I’m not sure, whether I have to click anywhere more to complete the review. So instruct me if something missing.
Regards,
Martin
Martin Schönbeck May 7, 2021 at 9:28 PM
Hi @Carlos Ruiz,
ok. I’ll have to prepare my system anyway and will test it then.
Regards,
Martin
Carlos Ruiz May 7, 2021 at 9:12 PM
Hi @Martin Schönbeck - no, we don’t have yet a set up for test servers on pull requests - that would be a nice feature to add.
Regards,
Carlos Ruiz
Martin Schönbeck May 7, 2021 at 9:06 PM
Hi @Carlos Ruiz,
I just changed my working system and have to setup again to be able to compile iDempiere. Is your solution available on any of our test servers?
Regards,
Martin
Carlos Ruiz May 7, 2021 at 8:19 PM
Hi @Martin Schönbeck
The pull request 678 implements a solution for both issues reported by you:
leave the box empty if the initial value is zero
remove leading zeroes from the calculation to avoid octal mathematics done by default by javascript
the octal was problematic not just in the leading zeroes, for example this calculation “51+063” is calculated wrongly as 102
when removing the leading zeroes it was complicated as there are valid leading zeroes when they are behind a decimal point - I found an elegant solution at https://stackoverflow.com/a/55031565/1968443
As we’re modifying the way the calculator works - please test the most possible scenarios involving all operators, parenthesis, percentage, etc
Regards,
Carlos Ruiz
While the versions before 8.2 open the calculator with the value marked since 8.2 the value is not marked. So simply entering the intended value leads to a wrong entry. Trying to start e.g. QtyEntered with an empty field leads to a zero which then is presented in the calculator. Entering the intended value behind this zero leads to interpreting this value as octal value.