Resolving Embedded View Parameter Replication Failures

What the screen is telling you is specific: a composite label that should read USB 1A is missing one contributing value, or an embedded view still shows an older definition after a parameter or component changes. Trace the value from the label binding to the base-view parameters, then through the embedded-view input mapping. Two separate faults can produce a similar display: a binding that does not react to every dependency, and stale parameter configuration left behind after an edit.

Which failure does the screen show?

Do not start by deleting and recreating the view. That can remove the stale configuration, but it also hides whether the defect is in the binding, the embedded input mapping, or the stored property configuration.

Does the label react to every parameter?

A reactive binding updates when one of its registered dependencies changes. A common failure appears when a label binds to one parameter while a script transform reads several others. The bound parameter is the trigger; values read indirectly by the transform may not register as independent triggers. The label can therefore contain correct expression logic yet remain stale until the primary parameter changes.

1. Open the label property that produces the displayed text.
2. List every view parameter used to create the label. The reported label uses three of four parameters, including roomNo.
3. Change one contributing parameter at a time while watching the label.
4. If every change immediately recalculates the text, continue to the embedded input check.
5. If only the primary bound value triggers an update, rebuild the binding so every contributing value participates in the reactive dependency.

Two configurations can work. A direct expression binding is simpler when it references every contributing parameter explicitly. An object parameter containing the text fields also works: bind the label to that object so a change to any field updates the object binding. Prefer the object when the fields travel together through embedded views because it reduces separate mappings and avoids hidden transform dependencies.

Do the embedded inputs match the base view?

Adding or renaming a base-view parameter does not by itself define the value passed by each embedded-view component. The embedded instance must expose a matching input name and supply the intended value. The tag may be right; the binding is wrong when the controller value reaches the project but the embedded input still uses an obsolete name.

1. Write down the current base-view parameter names exactly.
2. Open each embedded instance and compare its input names character for character.
3. Add mappings for new parameters and replace mappings that still use an old name.
4. Change the source value and observe the embedded parameter before judging the label.

If the embedded parameter changes but the label does not, return to the label dependency test. If the embedded parameter never changes, continue into the serialized configuration.

Does propConfig retain the old name?

The identified defect occurred when adding or renaming parameters failed to set their configuration correctly. The visible parameter name could look correct while propConfig still contained an object named for the previous path, such as params.roomNo. Embedded values then targeted a view definition whose stored configuration did not agree with its current parameter list.

1. Use Shift+Right Click on the view in the project browser.
2. Select Copy JSON.
3. Paste the copied JSON into a plain-text editor.
4. Find the propConfig object.
5. Look for a child object whose name contains the old parameter path.
6. Compare that path with the parameter currently shown in the base view.

A matching current name moves the diagnosis back to the embedded mapping or label binding. An obsolete name identifies the stale configuration branch and calls for the JSON repair.

How do you repair the stale view configuration?

Preserve a copy of the exported JSON before editing. Change only the obsolete property-path key; broad edits can alter unrelated view properties.

1. In the copied JSON, replace the old key inside propConfig with the current parameter path.
2. For example, change the obsolete path to the current name in the same form as params.roomNo.
3. Select and copy the complete edited JSON document.
4. Return to the designer and use Shift+Right Click on the same view.
5. Select Paste JSON to replace the view with the corrected definition.
6. Save the project and reopen the embedded instance.

This repair avoids deleting and rebuilding the view. A corrected build was uploaded on 2/4, although no version string is identified. Read the installed product version and compare it with the official release history before deciding whether the JSON workaround is still required.

How do you verify the resolving branch?

Verification must exercise each dependency independently; seeing one correct initial value is not enough.

1. Open the base view directly and confirm that its current parameter list contains no obsolete names.
2. Open the embedded instance and confirm that every input name matches the base view.
3. Change each of the three values used by the composite label, one at a time.
4. Confirm that each change appears without changing another parameter to trigger a refresh.
5. Rename or add a test parameter, update its embedded mapping, save, reopen the view, and inspect propConfig if the instance remains stale.
6. For the reported display, supply the intended values and confirm that the final label reads USB 1A.

FAQ