Widget references and scope
Widget.Using puts another QWidget inside the current widget. The child has its own data, inputs, function results and triggers; the parent gets read-only access.
Reference forms
Accessing state
The parent cannot write child state; for coordination, pass inputs through
Arguments or keep the logic inside the child. When Widget.Outputs is declared, Data / Results are no longer exposed and the parent can only read Outputs.
Arguments
- Supports
{Inputs.*}/{Data.*}/{Results.*}interpolation. - Invalid JSON shows an error placeholder.
- The child’s
Inputsare initialized with these values; changes toArgumentsupdate the corresponding inputs, and the child can still change its own inputs.
Dependency resolution
- Local Name: looked up by name in the custom widget list. Missing shows “local widget not found”; duplicates show an ambiguity error.
- Remote Url: fetched and validated through the backend proxy; fetched on first reference, then updated silently per the TTL.
- Export: only the current widget is exported, dependencies are not inlined; missing local dependencies are reported before export.
- Sharing: dependency widgets must be distributed separately, or referenced by
Urlinstead.
Cycles and depth
- Maximum nesting depth 5.
- Self references and A→B→A cycles are detected; an error placeholder is shown once detected.
- At most 20
Widget.Usinginstances per parent widget. - Duplicate aliases fail during parsing.
Lifecycle
- A child runs its own
Data,TriggersandFunctionindependently. - Unmounting a child cleans up its timers, script sandbox and Blob URLs.
- The same local widget referenced multiple times shares the data cache, but inputs/results stay independent.
Security
- Remote nested widgets use the same silent update logic as top-level widgets.
- Their data domains are listed for confirmation in the parent widget’s editor.
- If a child contains scripts/commands, the parent editor shows a risk banner.