EEZ Studio Embedded Dashboard Parameters: Treat Host Values as Continuing Assignments

Embedded Dashboard parameters are continuing assignments from the host, not merely startup defaults for the child. If a child variable can also be edited locally, a later host evaluation can write it again. A value that appears to revert may therefore have two legitimate writers rather than a broken input widget.

The Embedded Dashboard documentation says parameter names must correspond to global variables in the external Dashboard and that host-side expressions are continuously evaluated. The pinned implementation makes that direction explicit.

The scope here is EEZ Studio v0.29.0 commit 3000161d09d40a5c1dc2477ddc30b38037b3a612. An Embedded Dashboard creates a separate Dashboard runtime; it is not the same mechanism as a reusable LVGL user widget inside one project.

The name resolves into the child's compiled globals

After loading the child runtime, updateGlobalVariablesWithDashboardParameters establishes an autorun. For each configured parameter, it evaluates the host-side value expression, finds the named global in the child's assets map and converts the value using that global's compiled type index.

It then calls the child runtime's global-variable setter and frees the temporary converted value. The update is therefore directed from an evaluated host expression to a specific child global. The name is an interface key, not just descriptive text attached to the embedding widget.

If the name cannot be found, the inspected code logs an invalid-dashboard-parameter message. It does not create a missing global automatically. A child refactor that renames an exposed global needs a matching review of the host parameter list.

A child edit does not establish reverse binding

The shown update function writes child globals. It does not implement a matching listener that copies arbitrary child edits back into the host expression's source. Do not infer bidirectional binding from the fact that a value is displayed and editable in both Dashboards.

For an illustrative fixture, the host supplies a target value of 10. The child receives it and an operator changes the child's local value to 12. Now change the host value to 20. The documented update direction predicts another assignment of 20 to the child when the host expression is reevaluated.

Do not assume an exact overwrite time when the host has not changed. Autorun tracks reactive dependencies, and this source inspection does not establish every reevaluation trigger. The discriminating fixture deliberately changes the host dependency so the continuing assignment is observable without relying on incidental rendering.

Decide which values the host owns

A host-owned input is useful for configuration that the child should consume but not independently redefine. Give that input a clear role in the child. If operators need to edit a candidate locally, keep the candidate separate from the host-provided value and define an explicit acceptance path.

For a value that should be child-owned after initialization, do not assume a continuously configured parameter becomes an initializer just because its host expression usually stays constant. Use a supported initialization arrangement or a separate parameter indicating when and how the child should copy an input into its own working state.

These are application interface choices. The source does not supply a general transaction, conflict-resolution rule or automatic child-to-host result channel. The intended ownership must be visible in the project design.

Test the parameter contract with different names and types

Create a small child with one clearly named global and a label showing its raw value. In the host, bind one parameter to that name. Change the host value while the child remains mounted, then make a child-local edit and change the host value again.

Next, deliberately misspell the parameter name in a disposable copy and observe the reported failure. This separates a name-resolution problem from a value-conversion problem. For type changes, inspect the compiled child global type because that is the type index used during conversion; a matching name alone is not a compatibility guarantee.

No Dashboard was loaded or edited during this research. These are proposed fixtures based on the documented assignment direction and pinned code. They help answer the practical question behind a reverting field: did the child fail to retain an edit, or did the host supply a new authoritative input through the interface it still owns?