Differentiating Object Properties in WinCC WebUX vs Client

Differentiating Object Properties in WinCC WebUX vs Client Runtime

WinCC V7/V8 and WinCC Runtime Professional share one picture database between the native WinCC Client, WinCC WebNavigator, and WinCC WebUX. Because the picture and its object properties live in the server project, the same color, visible, or position value reaches every viewer. This article consolidates field-proven methods to detect whether a screen is being rendered by a native WinCC Client or by a WebUX browser session, and to drive object properties accordingly.

1. Problem Statement and Scope

A typical requirement is "the same page, different appearance":

• A button is larger, with full text, on a WinCC Client (touch or 24" operator station).
• The same button is smaller, with abbreviated tooltip, on a WebUX browser session running on a tablet.
• Color palette shifts because the WebUX client does not support a custom ActiveX control, but the native Client does.

WinCC WebUX is the HTML5-based successor to WebNavigator. WebUX uses an in-house browser-independent rendering engine (Siemens' "Plant WebUX" client) that streams VSTA-compiled screen objects through HTTPS, while WebNavigator is an ActiveX-based plug-in for Internet Explorer. The two have very different scripting and object support surfaces, which is why property differentiation is needed in the first place.

2. Why ifdef RUN_ON_WEBNAVIGATOR Does Not Work in WebUX

The classic WinCC preprocessor directive is:

// C-Script in Graphics Designer
#ifdef RUN_ON_WEBNAVIGATOR
    SetPropChar(lpszPictureName, "Button1", "Caption", "WebNav");
#else
    SetPropChar(lpszPictureName, "Button1", "Caption", "Client");
#endif

This directive is resolved at compile time of the C-script project. It evaluates to True when the project is compiled for a WebNavigator client target, and False for a native WinCC Client. There is no RUN_ON_WEBUX macro in WinCC V7.x/V8.x as of the TIA Portal V20 / WinCC V8.1 documentation set. Therefore, conditional compilation is not a viable method when WebUX is the target.

3. Runtime Context Detection Methods

Because compile-time selection is unavailable, three runtime mechanisms are used in practice:

1. Internal tag @LocalMachineName - returns the local machine identifier, which differs in format between a native Client and a WebUX client.
2. User-based differentiation - assign separate WinCC users to native Client operators and to WebUX users; use the GetUserName API or the configured operator station rights to switch properties.
3. Separate screen objects / separate pictures - the most reliable method when the visual change is large (e.g., an HTML5-friendly control vs. a WinCC native control).

4. The @LocalMachineName Approach

The internal tag @LocalMachineName is a string that WinCC populates per client session. Its value depends on the runtime context:

Field-proven behavior: in WinCC V8 with the WebUX server role enabled, the @LocalMachineName tag observed in a WebUX browser session returns the IP address of the machine hosting the browser when the browser is external. When the same browser runs on a real WinCC Client PC, the tag returns the client's computer name - making differentiation between "native client" and "WebUX on native client" impossible using this tag alone.

4.1 Practical C-Script Example

// Triggered on picture open
#include "apdefap.h"
void OnOpen(char* lpszPictureName, char* lpszObjectName, char* lpszPropertyName)
{
    char* szLocal = GetTagChar("@LocalMachineName");
    // IP-like content: contains digits separated by dots
    int bIsWebUX = 0;
    if (strlen(szLocal) > 0) {
        int dots = 0, digits = 0;
        for (int i = 0; szLocal[i] != '\0'; i++) {
            if (szLocal[i] == '.') dots++;
            if (szLocal[i] >= '0' && szLocal[i] <= '9') digits++;
        }
        if (dots >= 3 && digits >= 4) bIsWebUX = 1;
    }

    if (bIsWebUX) {
        // WebUX: small button, short caption, dim color
        SetPropChar(lpszPictureName, "Button_Ack", "Caption", "OK");
        SetPropWord(lpszPictureName, "Button_Ack", "BackColor", 0xC0C0C0);
    } else {
        // Native client
        SetPropChar(lpszPictureName, "Button_Ack", "Caption", "Acknowledge Alarm");
        SetPropWord(lpszPictureName, "Button_Ack", "BackColor", 0x00FF00);
    }
}

5. User-Based Differentiation

The most robust method, used by integrators when context cannot be inferred reliably, is to create two distinct WinCC users:

• OP_WebUX - assigned only to operators who log in via the WebUX portal.
• OP_Client - assigned only to native client operators.

Both users can be linked to the same authorization level (e.g., level 4 "Process control"), so functional rights are identical. Differentiation is purely cosmetic.

5.1 Detecting the Logged-in User from a Script

// Returns the currently logged-in WinCC user (or "" if not logged in)
char* szUser = GetUserName(lpszPictureName);

if (strcmp(szUser, "OP_WebUX") == 0) {
    // WebUX look-and-feel
    SetPropBOOL(lpszPictureName, "ctrlHTML5Chart", "Visible", 1);
    SetPropBOOL(lpszPictureName, "ctrlWinCCChart",  "Visible", 0);
} else if (strcmp(szUser, "OP_Client") == 0) {
    SetPropBOOL(lpszPictureName, "ctrlHTML5Chart", "Visible", 0);
    SetPropBOOL(lpszPictureName, "ctrlWinCCChart",  "Visible", 1);
}

5.2 Detecting the User via Tag

The internal tag @CurrentUser always returns the user name string for the active session. Linking a tag connection to a project-wide dynamization is generally simpler than scripting per object:

// Dyn configuration of a property, type "Tag/Value"
Tag:    @CurrentUser
Comparison type: string
Value:  OP_WebUX
On TRUE:  set object property to "WebUX variant"
On FALSE: set object property to "Client variant"

6. WebNavigator vs WebUX - Object Property Surface Differences

When property differentiation is required, it is usually because the two clients support different object sets. The following table summarizes the most common gaps encountered in field projects.

7. Enabling WebUX on a Screen Object

By default, picture objects are not published to the WebUX client. To make an object available:

1. Open the screen in the Graphics Designer (WinCC V7/V8) or in the TIA Portal editor (RT Professional).
2. Select the object and open Object properties > Miscellaneous.
3. Set the property Web-enabled to Yes.
4. Recompile / republish the WebUX project (button "WebUX Publisher" or via the WebUX configurator).

For TIA Portal V20 / WinCC Runtime Professional, the same property is set in the Inspector window of the screen editor: Configuring WinCC screens for WebUX (RT Professional).

8. Supported Screen Objects in WebUX

WebUX supports most static and dynamic screen objects, but not all. The official list is published in the TIA Portal help:

• Static objects: line, polygon, ellipse, rectangle, static text, graphic view.
• Smart objects: I/O field, button, option group, bar, slider, date/time field, text list, combo box, list box.
• Windows: picture window, screen window.
• WinCC Controls (selected): Alarm Control, Online Trend Control, Online Table Control, Function Trend Control, User Archive Control, RulerControl, Browser View (HTML), Process Control.

Not supported in WebUX: custom ActiveX, OCX, faceplate instances that internally use unsupported objects, and several Smart objects depending on WinCC version. Always verify against the current TIA Portal help page Supported functions: Screen objects (RT Professional) before designing dual-target screens.

8.1 Property Restrictions That Apply to All Objects in WebUX

• Geometric rotation (property "Rotation") is not supported.
• Property "Layer" is read-only at runtime.
• Property "Operability in the monitoring" cannot be toggled dynamically when the object uses HTML5 rendering.
• Custom-defined properties on faceplates may be missing in WebUX if they target a non-supported type.

9. Scripting Pattern: Property Switching via VBS on Picture Open

For RT Professional (TIA Portal), VBS is the recommended scripting language. The pattern below detects the user and applies a property set per session.

' Trigger: Picture > Event > Opened
Dim sUser, bWeb
sUser = HMIRuntime.Screens("Main").Tags("@CurrentUser").Read
bWeb  = (sUser = "OP_WebUX")

If bWeb Then
    HMIRuntime.Screens("Main").Items("Button_Ack").Properties("Caption") = "OK"
    HMIRuntime.Screens("Main").Items("Button_Ack").Properties("BackColor") = RGB(192,192,192)
    HMIRuntime.Screens("Main").Items("ctrlTrendWin").Properties("Visible") = False
    HMIRuntime.Screens("Main").Items("ctrlTrendHTML").Properties("Visible") = True
Else
    HMIRuntime.Screens("Main").Items("Button_Ack").Properties("Caption") = "Acknowledge"
    HMIRuntime.Screens("Main").Items("Button_Ack").Properties("BackColor") = RGB(0,255,0)
    HMIRuntime.Screens("Main").Items("ctrlTrendWin").Properties("Visible") = True
    HMIRuntime.Screens("Main").Items("ctrlTrendHTML").Properties("Visible") = False
End If

10. Topology: Where Property Switches Happen

The diagram below summarizes where the differentiation logic lives in a typical WinCC V8 architecture with WebUX enabled.

11. State Machine: Picture Open Behavior

12. Verification Checklist After Configuration

1. Republish the WebUX project on the server. WebUX clients cache the published result - they do not pick up "live" changes to the server project.
2. Log in as OP_WebUX from an external browser; confirm @CurrentUser = OP_WebUX via the WinCC tag browser (HMI control "Diagnostics").
3. Log in as OP_Client on a native WinCC Client; confirm the script took the "else" branch and the original caption is shown.
4. Open a picture window that uses a faceplate with user-dependent properties. Verify that faceplate instances do not retain the previous user's settings after a user change.
5. Test on the WebUX host machine itself (browser opened on the WinCC Server or a WinCC Client). Confirm whether the same browser is recognized as "external" or "local" - this depends on the URL used (localhost vs. FQDN).
6. Verify back color and caption changes in the runtime diagnostics window. Use the "Watch" pane to inspect HMIRuntime.Screens("Pic1").Items("Button_Ack").Properties("BackColor") on both clients.

13. Field-Proven Best Practices

• Always combine @LocalMachineName detection with a user check. The two together eliminate false positives and make renaming of clients non-fatal.
• Use the WebUX Publisher cache as the source of truth in change-management processes. Old pictures will otherwise keep showing in cached browser sessions until republish.
• When the appearance difference is large, prefer two parallel pictures with a user-dependent picture-window redirection - it is more reliable than dynamizing 30 properties in a single picture.
• For C-scripts that call SetPropChar, SetPropWord, or SetPropBOOL, only call them on properties that are listed as runtime-writable in the WebUX object reference. Calling a non-writable property logs a runtime warning and is silently ignored on some firmware levels.
• Reserve ActiveX-specific logic for native clients and HTML5-friendly controls for WebUX - do not try to hide the unsupported control through Visible = 0 if the object itself is not Web-enabled (the picture will fail to load entirely).
• Document the user-naming convention (OP_WebUX, OP_Client, OP_Nav) in the project configuration document. The same convention is also used in Siemens' WebUX documentation examples.

14. Limitations and Constraints

• Conditional compilation is not available for WebUX in WinCC V7/V8. Plan for runtime dynamization only.
• Object name and layer cannot be changed in WebUX at runtime. If your differentiation requires moving objects between layers, use separate pictures.
• Picture window contents are not user-dependent by default; you must implement the picture selection yourself in the OnOpen event of the parent picture.
• WinCC faceplate instance properties are partly read-only in WebUX. Refer to the TIA Portal V20 supported functions page for the current matrix.
• Scripting in WebUX follows the WebUX Controls and Scripting restrictions: not all methods available in WebNavigator work in WebUX, and Siemens explicitly recommends setting properties directly on the control instead of using indirect methods.

15. Quick Reference: Object Property Methods

16. Frequently Asked Questions