Could we get an additional String constructor to specify the number of significant figures in a float value (as apposed to decimal places).
When using certain values with a large range - such as frequency - it’s nice to be able to keep the displayed values a consistent length (20.000, 200.00, 2000.0, 20000). At the moment I can manage this with a rather ugly if-else block and setting the String’s decimal places based on the value but it would be nice to be able to do this in one line.
perhaps it has changed recently but in the tip the argument is ‘maxNumberOfDecimalPlaces’
/** Creates a string representing this floating-point number.
@param doubleValue the value to convert to a string
@param maxNumberOfDecimalPlaces if this is > 0, it will format the number using no more
decimal places than this amount, and will not use exponent
notation. If 0 or less, it will use a default format, and
exponent notation if necessary.
@see getFloatValue, getIntValue
*/
String (double doubleValue, int maxNumberOfDecimalPlaces);
ah… ok! that’s why I noticed that only recently too!
Perhaps that’s something that should be added to the “breaking change” file?
it won’t “break” things, but it can have a strong impact on the UI (like on the sliders values…).
btw: sorry that I did not start a new thread. It was just supposed to be a side question at first, not a bug report
I agree, it’s not going to cause any crashes (touches wood) but will likely cause some UI weirdness as you said. To be honest, I’d rather have the old functionality back too!
Any normal person will thing that maxNumberOfDecimalPlaces = 0, means that “Number Of decimal Places” - well is … zero
Whats is even more mean, you cannot even search your whole codebase, because its the constructor which has changed its behaviour, so you have probably have a lot of wrong hits when you search for the String() constructor
This is creating problems for me too, we have a lot of code that relies on the old String(double doubleValue, int numberOfDecimalPlaces) behavior. When upgrading to JUCE 5.4.1 a lot of our tests are now failing. It would be nice to re-instate the old behavior and to have a different API for the new approach.