This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
We had a bug reported in a beta release of 6.0 that a customer was having trouble disabling a Tool Container. Looking into it, I didn't see any issues, everything seemed to be working fine. This was an advanced user though who doesn't usually report stuff incorrectly.
Once I fired up the module supplied by the user, I saw the issue:
They were updating the value from a formula. The value in the XML was expecting to be "True" or "False".
The formula works a little differently, a boolean expression like the above results in a number, 0 indicating false, non-zero (by default –1) would be true. I could have told the user to change their formula to if NOT [Rout B] then "true" else "false" endif
Even though this wasn't a bug per-se, having 2 different parts of the engine interpret boolean values differently was confusing. The good news here is that the code that reads a boolean value out of XML is shared across the entire engine, so it was really easy to make a change that would impact everywhere we read a value from XML. We made the simple change when reading a boolean that in addition to looking for "True" or "False", it also checks that if the value is a number, it will read it as 0 for false, non-zero for true.
A very small change for an equally small usability improvement, but it felt good to be able to make the engine adapt to the user instead of the other way around. It is also nice that this fix is global, it applies as much to a detour as the container and I am sure lots of other places in the engine.