Closed benloh closed 1 year ago
requested review from @jdanish
In GitLab by @jdanish on Oct 5, 2022, 04:01
This appears to work. Thanks!
added 1 commit
Also just pushed a fix to the equal
, notEqual
methods for the boolean class so that they are properly logical operations, not assignments.
(Fixes problem where calling equal
would assign the new result of the comparison value to the boolean value.)
@jdanish
In GitLab by @jdanish on Oct 7, 2022, 11:07
Looks good.
mentioned in commit e86ca84951713b8acf81dad1ba6aee98eb13d01b
Merges dev-bl/fix-default-bool -> dev-next
The Problem
The default value for a new
class-sm-boolean
object isundefined
. This is consistent with other GVars. When you first edit a GVar slot, you need to set a value before it is redefined from 'undefined'. This is fine for strings and numbers, but for a boolean we use a slider that is always in either "False" or "True" position. There is no "undefined" position. So the UI gives the mistaken notion that the value is already set to "False" when in fact it is undefined.Solution
There isn't an easy solution here. GVars by default should remain undefined so we know if they've been set. So we don't want to set the boolean value to false by default.
We can try to set the value to false when the empty UI slot is first selected, but we can't set the value directly, since it is a lineslot token. We have set it through ac-editmgr.
So we've added a hack that when the boolean input first opens and detects an 'undefined' value, it sends an immediate state update to ac-editmgr. This results in a few extra state update calls, but it's probably the cleanest way to do this since we want the UI element to update with new state data anyway.
To Test
addProp xxx boolean