Fix T38722: Adding units in Imperial setting results in inconsistent values

Now always check for a default unit, and evaluate the whole expression in this "unit space".
Not an ideal solution, but should handle most cases nicely
(we can't address all possible corner cases anyway).

Note default unit is searched in current string first (bigger unit of current system wins),
then in previous string.

Note this also replaces ',' by '+' in default separation between units,
helps solving issues with parenthesis (e.g. (1'1")*2.5 would fail in existing code)!
This would break if someone uses py ops with lower precedence than '+' (like bitwise
operations, and comparison), but these are not expected usecase here anyway.

Reviewers: campbellbarton

Differential Revision: https://developer.blender.org/D340
This commit is contained in:
Bastien Montagne
2014-08-20 12:12:03 +02:00
parent 21da42bd7a
commit 8535b9bd15
2 changed files with 69 additions and 49 deletions

View File

@@ -23,7 +23,10 @@ class UnitsTesting(unittest.TestCase):
('METRIC', 'LENGTH', "33.3dm", "1", 0.1),
('IMPERIAL', 'LENGTH', "33.3cm", "1", 0.3048), # ref unit is not in IMPERIAL system, default to feet...
('IMPERIAL', 'LENGTH', "33.3ft", "1\"", 0.0254), # unused ref unit, since one is given already!
#('IMPERIAL', 'LENGTH', "", "1+1ft", 0.3048 * 2), # Will fail with current code!
('IMPERIAL', 'LENGTH', "", "1+1ft", 0.3048 * 2), # default unit taken from current string (feet).
('METRIC', 'LENGTH', "", "1+1ft", 1.3048), # no metric units, we default to meters.
('IMPERIAL', 'LENGTH', "", "3+1in+1ft", 0.3048 * 4 + 0.0254), # bigger unit becomes default one!
('IMPERIAL', 'LENGTH', "", "(3+1)in+1ft", 0.3048 + 0.0254 * 4),
)
# From 'internal' Blender value to user-friendly printing