Diagnose popup window property scripting

Symptoms and what they point to

Start by separating command execution, window lookup and appearance changes. Each can fail independently.

• The popup opens, but the property assignment has no visible effect: the assignment may target the numeric command result rather than the popup object.
• The property assignment throws a type error: inspect the assignment target. A numeric primitive is not a window object.
• Similar code works for a faceplate popup: the two opening methods may have different return contracts. One working example does not establish what another method returns.
• The popup does not open: investigate the command status and arguments before attempting a property write.
• The window lookup returns nothing: check the lookup scope, window instance name and documented creation timing.
• The property reads back correctly, but the appearance stays unchanged: check whether the selected bits control that feature and whether the property can change after creation.

Do not begin by trying unrelated flag numbers. First establish which object receives the assignment.

Confirm the return value contract

Open the manufacturer's JavaScript object-model documentation for the exact runtime version in use. Find the reference for HMIRuntime.UI.SysFct.OpenScreenInPopup, then read its return-value definition and example together.

For this method, treat the returned number as a command status. Check the documented success value and the meaning of other results. Do not infer the success convention from a different API, and do not interpret a successful result as proof that a later object lookup must already succeed.

Name the variable accordingly. A name such as openStatus makes the contract clearer than a name that suggests a popup reference.

JavaScript helps explain the misleading symptom. In non-strict execution, assigning a property to a numeric primitive can be ignored without changing anything useful. In strict mode, the same kind of assignment throws a TypeError. Neither behavior changes the live window.

Where the runtime supports strict mode, it can expose this mistake earlier during development. It does not replace checking the API contract, and it should not be introduced across an existing project without reviewing the scripts it affects.

Do not extend this diagnosis to every method in a namespace. Read the return contract for each method you actually call.

Retrieve the live popup window

The command opens a screen in a window. The hosted screen and its window instance are different things, even when their names happen to match.

Use the screen-window retrieval example supplied with the opening method in the documentation for your runtime version. Do not invent an accessor from an older project or assume that a faceplate object and a screen window expose the same interface.

Work through the lookup in this order:

1. Identify the arguments. Confirm which argument names the screen and which names the popup window instance. Check the complete parameter table, including optional arguments.
2. Keep the instance name available. Use the same name when retrieving the window. Distinct, descriptive screen and window names make mistakes easier to spot.
3. Check the opening status. Stop the property-update path if the command reports failure. A lookup error after an unsuccessful opening command is secondary evidence.
4. Use the documented lookup scope. Confirm where the runtime exposes the created window and how the lookup identifies it.
5. Validate the result. Check for an absent result, then establish that it is the documented screen-window object with the required property.

A typeof check is useful but incomplete. In JavaScript, null reports as object, and an ordinary object can accept a property that has no connection to the runtime window. The important check is the object's documented identity and interface, not just its broad language type.

If the lookup is empty immediately after opening, timing is one possibility, not the only explanation. A wrong name or lookup scope can produce the same symptom. Use a documented lifecycle event or deferred callback where required. Do not use a tight waiting loop inside a UI handler; it can block the work needed to finish creating or displaying the window.

Check what WindowFlags permits

Once you have the live screen-window object, read the WindowFlags property reference for that same runtime version.

Confirm all of the following before assigning a value:

• The property belongs to the retrieved object type.
• It is writable in the current runtime and at the intended point in the window lifecycle.
• The documented bits control the border, caption or other feature you want to change.
• The value describes enabled features or suppressed features, as specified by the property reference.
• The assignment replaces the complete mask or modifies selected bits in the way you intend.

A copied decimal value hides these decisions. Prefer descriptive constants based on the documented bit definitions. Combine independent flags with bitwise OR when the API defines them as a bit mask. Do not assume that adding values is equivalent, especially when the same bit could appear more than once.

Also decide whether existing flags should be preserved. Replacing the entire mask can change unrelated window behavior. Reading the current mask and changing selected bits is appropriate only when the property's documented semantics support that approach.

If every instance should have the same appearance, check whether the engineering configuration can express it directly. A static setting avoids a runtime lookup and a timing dependency. Use scripting when the appearance genuinely needs to vary.

Verify the fix at each boundary

Use a development runtime or an approved maintenance test arrangement. Keep the machine in a safe condition, and do not remove required access to alarms, navigation or closing controls merely to obtain a cleaner appearance.

Record a short diagnostic sequence:

1. Opening result: capture the status type and value, then interpret them using the method reference.
2. Window identity: record the requested instance name and confirm that the lookup resolves the intended window.
3. Property before writing: read the current value if the property supports reading.
4. Property after writing: read it again and compare it with the intended mask.
5. Visible result: confirm that the intended border or caption changes and that unrelated controls remain usable.
6. Lifecycle behavior: close and reopen the popup, then repeat the normal calling sequence.

A successful read-back is evidence that the object accepted the value. It is not, by itself, proof that every requested visual feature is supported or immediately redrawn. If the mask matches but the appearance does not, return to the property's supported bits, write timing and target-runtime limitations.

If the entire HMI view is clipped inside its host rather than just the popup border being wrong, investigate kiosk browser sizing in an HMI window as a separate layout problem. Window appearance flags do not correct the host's dimensions.

Prevent the same fault after changes

Keep the command result and window reference in separate variables. Preserve that distinction in helper functions as well: a function returning a status should not be named or documented as though it returns a window.

For multiple popup instances, follow the runtime's documented naming and reuse rules. Do not assume that opening with the same name creates another independent window. Retain the instance identifier used for subsequent updates and closing operations.

After a runtime upgrade, repeat the opening, lookup, assignment and visual checks. Confirm that the documentation branch matches the deployed runtime, not just the engineering software installed on a workstation.

The reliable correction is not a different unexplained number. It is a complete chain: a successful opening command, a valid live-window lookup, a supported property assignment and a visible result that matches the requirement.

Questions