Brian wrote: ↑October 1st, 2020, 6:30 amThis lies within a grey area of "expected behavior".
Aren't they all?
Brian wrote: ↑October 1st, 2020, 6:30 amIt basically comes down to a trade off between accuracy and speed.
Yep, that's what I thought. In this particular case, I'll go with speed, since my simulator already takes a bit (too much) of CPU due to the actual (or virtual, even though they are inside a Container) size of the meters (e.g. orbital ellipses and such, redrawn every 25 ms despite their negative UpdateDivider, just because they belong to the same skin as the actual animated tiny Shape meters of the celestial bodies).
Brian wrote: ↑October 1st, 2020, 6:30 amHere is the code that deals with this. Changing its precision from "5" to something larger is easy...but is doesn't solve any other areas where this "precision assumption" is used (like in the About dialog). Ideally it would be better to provide some way of defining precision per skin or "on demand" for certain calculations. Finding the best solution that gives the most flexibility while not having much negative performance is somewhat tricky.
I understand. As I said, I go with performance on this one, since fortunately inside a Calc measure the issue seems to be somewhat alleviated (by the way, is there such a limit in Calc measures?), and I already had to use those measures to resolve potential formulas to actual numbers that can be shown to the user, so no big deal. As for a way of defining precision by skin, a simple
DecimalPrecision=N option in the
[Rainmeter] section will probably be enough. Not sure about the negative performance impact, that's your call to weigh in if it would be bearable or not.
As always, thanks for answering and providing the technical details of this - much appreciated.