The click path is simple: the operator selects a button, the button event calls the pop-up action, the runtime resolves the target view and instance identifier, and the placement settings position it in the viewport. Follow that path in order. Coordinate calculations matter only after the event and view resolution succeed.
Where does the pop-up request stop?
Layer one first: confirm that the operator can select the control and that the active button actually owns the expected action. This application has six button sets in a left docked view, with one set visible at a time according to the tab-container selection. The same seven pop-up choices can also be selected from the body overview. That creates two possible request origins for each target.
| Path check | Reading to take | Outcome | Next check |
|---|---|---|---|
| Input | Does the button show its normal pressed or selected state? | No response points to hit testing, visibility, enablement, or an overlay. | Correct the input path before inspecting placement. |
| Event | Does a temporary diagnostic action execute? | A missing result means the configured event is not firing. | Inspect the button event and the active tab state. |
| View resolution | Does the target open with default placement? | Failure here points to the view reference or required parameters. | Correct the view and parameter mapping. |
| Placement | Does the view open, but at the wrong location? | The request reached the placement stage. | Inspect the pop-up command settings. |
Compare both entry paths. If the body button works but the left-dock button does not, the fault lies before the shared pop-up definition. If both open the same wrong instance or position, inspect their common identifier and placement configuration.
Which coordinate reference should control the location?
Use the pop-up command available from the action menu. Its lower-right options specify where the pop-up appears, can constrain the window to the viewport, and can place it relative to the mouse. This command exposes more placement controls than the script form described for the same task.
| Placement mode | Useful when | Reading or setting | Recurring pitfall |
|---|---|---|---|
| Explicit position | The pop-up must occupy a repeatable screen region. | Read the coordinate and anchor fields shown by the action editor. | Treating a container-relative coordinate as a viewport coordinate. |
| Mouse-relative | The selected object should open near the operator's pointer. | Select the relative-to-mouse option. | The window can approach an edge unless viewport containment is active. |
| Viewport-constrained | The complete pop-up must remain visible. | Activate the force-within-viewport option. | The runtime may shift the requested position near viewport boundaries. |
Do not infer the desired values from a design screenshot. Read the coordinate reference named in the action editor, then test it in the running viewport. Browser scaling, dock width, viewport size, and responsive layout can make design-surface pixels differ from the runtime location. Mouse-relative placement avoids the need to discover a view's fixed screen coordinates. For a right-side work area, viewport containment prevents part of the view from opening beyond the visible edge.
Does the instance identifier prevent duplicate pop-ups?
The Identifier property distinguishes pop-up instances. Build one stable identifier for each logical instance and send that same value from every button capable of opening it. A button in the left dock and its matching control in the body overview must not derive different identifiers for the same logical target.
| Identifier pattern | Result | Decision |
|---|---|---|
| One fixed identifier per logical pop-up | Every request addresses the same instance. | Use this when only one instance of that item may exist. |
| Identifier derived from a passed item key | Different items can have separate instances. | Use the same derivation in open and close actions. |
| Random or source-specific identifier | Repeated selections can create duplicates. | Replace it with a deterministic value. |
| No coordinated identifier | The two request origins cannot reliably address one instance. | Centralize identifier construction. |
The identifier solves instance identity; it does not by itself define layout or prove that selecting an existing instance raises it above every other window. Test that behavior in the deployed runtime. Open two identified instances, select the first again, and observe whether the existing instance moves to the front without increasing the open-instance count. If it does not, use a container-based presentation where selection and stacking are explicit.
When should the right dock own the layout?
A right-side dock with a flex layout removes free-floating coordinate and z-order problems. Add or remove embedded view instances from a managed collection, and let the flex container place them. When all entries are instances of the same view, a flex repeater can generate them from instance data. A scrollbar can support more entries than fit vertically.
| Requirement | Free pop-ups | Right-dock flex layout |
|---|---|---|
| Arbitrary screen location | Direct fit | Not the primary design |
| Prevent duplicate logical items | Requires disciplined Identifier values |
Keep one item key in the instance collection |
| Bring an existing item into view | Depends on runtime raise behavior | Select, reorder, or scroll to the managed entry |
| Many simultaneous instances | Windows can overlap | Flex layout and scrolling manage the space |
| Seven different target views | One command per target is straightforward | Use a managed list that includes the target view and its parameters |
Do not select a flex repeater merely because several items appear in the same area. It fits best when the entries share one repeated view structure. Seven genuinely different views require a common wrapper or a managed container capable of selecting the appropriate target. The six changing button sets can still write to one shared collection so the left dock and body overview produce identical behavior.
How do you configure the resolving branch?
- Choose one logical key for each of the seven pop-up choices. If a view can represent multiple equipment items, combine the view type with the item's existing key; do not use the button location as identity.
- Configure every matching left-dock and body button to call the action-menu pop-up command with the same target view, parameters, and derived
Identifier. - Open the command's placement controls. Select explicit placement when the location must be fixed, or select mouse-relative placement when the click location should drive it.
- Activate the option that forces the pop-up inside the viewport when edge clipping is unacceptable.
- Configure the close action to use the same
Identifierderivation as the open action. - If runtime testing shows that an existing identified window cannot be raised as required, move the presentation into the right dock. Store one entry per logical key and have button actions select or add that entry.
Keep target selection, parameter construction, and identifier construction common across both request origins. Copying similar actions across the six button sets invites one mismatched key or parameter set.
How do you verify position and reuse?
- Test every target once from the body overview and once from the currently visible left-dock button set. Record the target view, parameters, and
Identifierproduced by each path. - Open two different instances. Select the first again and confirm that no third instance appears.
- Close the first instance and reopen it. Confirm that the close and open operations address the same identifier.
- Repeat placement tests near the viewport's left, right, top, and bottom edges. Confirm that viewport containment keeps the full pop-up visible.
- Repeat at each supported viewport size and scaling condition. A fixed coordinate that works in one viewport can collide with a dock or move at another size.
- For a right-dock implementation, add enough entries to activate scrolling, remove one entry, and confirm that the collection and rendered instances remain synchronized.
FAQ
Can I get a pop-up's x and y position from the view?
Use the placement fields in the action-menu pop-up command and follow the coordinate reference shown there. If the requirement is simply to open near the selected control, use mouse-relative placement instead of calculating view coordinates.
Does the Identifier property stop duplicate pop-ups?
A stable Identifier lets every request address the same logical instance. Use the identical derived value in the left dock, body overview, and close action; then test that the open-instance count does not increase on reselection.
Can I keep multiple pop-ups inside the right dock?
Yes. A flex layout can arrange managed view instances, and a scrollbar can expose entries beyond the visible area. Use a flex repeater when the entries are instances of the same repeated view structure.
Does selecting an open pop-up always bring it to the front?
The Identifier establishes identity, but the raise behavior must be tested in the target runtime. Open two instances, reselect the first, and complete the final verification by confirming that it becomes visible without creating another instance.