Reported by Mathias Bavay, Mar 7, 2020
I've encountered a weird bug with the MULT filter: it originally had a declaration such as: <parameter key="%::ARG#::CST" label="CST" type="number" format="decimal" default="0" optional="false"> When using the filter, it was not possible to give a decimal number, only integers would work. Removing the default value allowed entering decimal numbers. Moreover the validation has some issues: entering "0" keeps the field marked as "mandatory"...
Comment 1 by Michael Reisecker, Mar 7, 2020
Comment 2 by Michael Reisecker, Mar 7, 2020
Fixed in commit fed6355. Precision: INIshell expected either precision="...", or it would parse the precision from the entered number, which in your case, was 0. 0.0 would have worked. Now for a decimal there must be at least 1 digit. The rules now are: - If the INI value's precision is greater than what can currently be displayed, the spinboxes precision is extended. - If there is no precision in XML, the INI value's will be used, but it must at least be 1. 1 is now also the default to make the logic easier. - If the currently displayed decimals are greater than the next INI value that is read, it will be set to the maximum of the INI value and default value (but again at least 1). - Possible inconvenience: default XML value is e. g. 1.2, no precision attribute set, but then the user wants to input 1.234. This can only be done by either loading an INI file with such precision, or entering it as expression. For high precision number we should just show a couple of decimals via "precision=...". Tested only quickly, but if something turns up it will be as quick of a fix. Validation: The reason was that if the box is at 0 and then 0 is entered, annoyingly no signal is emitted. I had circumvented this in our call already, but then didn't use it when improving hiding the value.