EEZ Studio ReadSetting: Test Saved Zero, False and Empty Strings Explicitly
A stored false value can be different from a missing setting, yet EEZ Studio ReadSetting can collapse both to null in the inspected implementation. Zero and an empty string follow the same path.
The ReadSetting guide describes null as the result for a missing key. The pinned ReadSetting implementation instead applies the expression readSettings(key) || null to the returned value.
This article concerns the Dashboard action at EEZ Studio v0.29.0 editor commit 3000161d09d40a5c1dc2477ddc30b38037b3a612. It does not generalize that expression to the persistent-global-variable save loop, native variables or every later release.
The fallback uses truthiness, not key existence
The logical OR expression returns null when the stored result is falsey. Therefore a returned false Boolean, numeric zero or empty string is transformed to null through this action, even though each can be a meaningful application value.
A nonempty string or another supported truthy value follows a different branch and passes through. A test that stores only a friendly string such as enabled can therefore miss the entire problem.
The distinction matters for optional preferences. A saved false might mean that an operator deliberately disabled a display feature; zero might be a valid count; an empty string might intentionally clear a caption. If the consumer interprets null as “use the default,” those meanings can disappear before the consumer gets to decide.
Isolate reading from writing and persistence
Use the documented WriteSetting action to prepare separate diagnostic keys with false, zero, an empty string and a nonempty sentinel. Read those keys alongside one deliberately absent key.
Record the actual type and value at ReadSetting's output before applying any default expression. Otherwise a second application fallback may hide whether the first transformation happened in the action or downstream.
Perform the first comparison within one controlled run. Then test the supported save/reload lifecycle separately if persistence across restart matters. Calling WriteSetting is not, by itself, evidence that the value has already been durably flushed to disk. This article's code observation is about reading the returned value through the OR expression.
Keep the variable names and keys distinct from production preferences. The inspected actions trim keys after validating them, so deliberate whitespace variants are not a reliable way to create separate diagnostic identities. Use explicit names such as testFalse and testZero.
Do not infer a reset rule from null
Once several input states have converged on null, a downstream Flow cannot reconstruct which original state was returned merely by inspecting that value. An application rule such as null means unconfigured is therefore stronger than the inspected action can establish for these cases.
Avoid repairing this with another unqualified fallback. First decide which values the application's supported representation must preserve. If a different supported API or action version distinguishes presence from value, verify that behavior directly.
An explicit tagged representation may be useful in some applications, but it is a design change that needs its own type and serialization tests. This article does not promise that every object wrapper, JSON type or imported project context is accepted identically by WriteSetting and ReadSetting. Replacing a Boolean with the text false also requires deliberate decoding; that text is not the same value as a Boolean false.
Turn the discrepancy into a small regression fixture
Keep the five-case comparison with the project: false, zero, empty string, truthy sentinel and absent key. Include the installed build identity and the raw output types. The fixture is small enough to rerun when upgrading the editor or changing the settings representation.
If the installed version preserves the falsey values, record that observation and inspect its implementation rather than assuming the older pinned expression still applies. If it produces the same null for several cases, prevent downstream default handling from pretending that key absence has been proven.
No settings action was executed here. The established finding is the exact source expression and its value transformation. The acceptance question is equally exact: can the chosen settings interface preserve every value the product intends to distinguish, before any fallback policy runs?
