UR Program Tree: Folders Are Children, Not Root Siblings

A folder insertion in a UR program tree uses the active program-tree location as its parent. If Ellipse is the last selected node, the new folder becomes an Ellipse child. The UR API cannot traverse from that location to Robot Program and insert the same folder there as a root-level sibling. Resolve the requirement by changing the node architecture: create a separate parent-node implementation comparable to Ellipse, or use the folder behavior represented under the basic commands tab.

Program-tree placement mechanism

The term root node here means Robot Program, the top of the visible program tree. A parent node owns nodes immediately below it, while a child node is inserted within that parent's scope.

The insertion operation is contextual. The selected or active node establishes the location in which the API can add or update children. It does not provide unrestricted navigation through the displayed hierarchy. Therefore, a request made while Ellipse is the active context creates a child below Ellipse; a desired visual destination elsewhere in the tree does not override that context.

This distinction separates tree presentation from API authority. Seeing Robot Program above Ellipse does not mean an extension can walk upward to it. The API supports work within the current parent context, not traversal to another parent. Repeating the insertion command, changing the folder label, or calculating a visual position cannot alter that ownership rule.

Check 1 — Active insertion context

Read the tree selection immediately before invoking the folder-creation action.

Do not diagnose this result as random placement. A folder repeatedly appearing under the last selected node demonstrates contextual insertion. Record the selected node and the resulting immediate parent as a pair; this removes ambiguity about where the operation actually ran.

Check 2 — Selection-to-parent relationship

1. Select Ellipse, invoke the existing folder action once, and inspect the folder's immediate parent. Expect: the folder appears below Ellipse.
2. Select a different eligible node, invoke the same action once, and inspect the new folder's immediate parent. Expect: placement follows the new active context rather than remaining fixed under Robot Program.
3. Compare both results without relying on indentation alone. Expect: each folder is owned by the context in which its insertion ran.

If placement follows the selection, continue to Check 3. If it does not, first inspect the action's actual invocation context: a callback or node-owned command may still execute on behalf of Ellipse even when another row looks highlighted. The deciding reading is the resulting parent-child relationship, not merely the highlight shown in the editor.

Check 3 — Root-parent capability

Determine whether the attempted design requires moving from the current node to a different parent. The UR API does not support multiple instances of parent nodes for this purpose and does not allow traversal from the parent location currently occupied to Robot Program. It permits adding or updating child nodes within the available context.

The wrong practice is to keep modifying child-insertion code while expecting it to acquire root-navigation capability. No child placement argument can create a parent relationship that the API does not expose.

Alternate parent-node design

Model the required construct as another parent node, following the same architectural pattern used to create Ellipse. This changes the problem from “move a folder upward from the selected node” to “define a node that owns its own children.” The existing folder function under the basic commands tab provides the relevant behavioral pattern: a folder is meaningful because it acts as a container, not because its label or icon changes its insertion level.

Keep the two responsibilities separate:

• The program-tree framework determines where the parent-node instance can be created.
• The parent-node implementation determines which child nodes it owns and how they are added or updated.
• The current selection determines the context for an ordinary child insertion.

If the real requirement is only to group operations inside Ellipse, retain the ordinary folder as an Ellipse child. If the requirement is a container independent of Ellipse, implement the separate parent-node pattern. Do not describe the latter as an ordinary folder forcibly inserted at the root; it is a different node architecture.

Resolution procedure and verification

1. Write down the required ownership relationship: either Ellipse → folder or Robot Program → separate parent-node construct. Expect: only one relationship matches the functional requirement.
2. For grouping local to Ellipse, invoke the folder insertion within that node's context. Expect: the folder appears immediately below Ellipse and accepts the intended children.
3. For selection-independent grouping, replace the ordinary folder-insertion attempt with a parent-node implementation patterned after Ellipse or the folder behavior under basic commands. Expect: the new construct owns its children instead of depending on traversal from Ellipse.
4. Change the selected program node and repeat the user action. Expect: an ordinary child still follows its active context, while the separate parent-node design preserves its own ownership model.
5. Inspect the final tree relationship. Expect: no resolving implementation depends on navigating upward from the current parent to Robot Program.

Frequently asked questions