InTouch Web Client Show/Hide Tags Button Not Working

InTouch Web Client Show/Hide Tags Button Not Working

Symptom: In an AVEVA (formerly Wonderware) InTouch deployment, a "Show/Hide tags" button placed on a project window (commonly stored in a shared library such as @Buttons11.PDL) toggles correctly on OS Clients and OS Servers but stops responding after a small number of clicks when the same window is opened through the InTouch Web Client. After the failure, all instruments on the page render without tag overlays, and the button no longer toggles state. The button is implemented through internal (memory) tags that drive object visibility on the graphics page.

This article documents the root cause (memory tag scope mismatched to the web client execution model), the architectural constraints of the InTouch Web Client, the correct tag scoping rules, and a verified procedure to restore toggle behavior across all web client sessions.

1. Problem Summary and Environment

2. Root Cause Analysis

The InTouch Web Client executes a thin-client session against the WindowViewer logic running on the Web Server host. Unlike native WindowViewer sessions, every web browser tab is a stateless HTTP/ASP.NET session that maps onto a single shared in-memory tag namespace on the Web Server. Memory (internal) tags in InTouch are scoped as one of two types:

• Shared (Project-wide): The tag value is part of the project database and is the same value for every InTouch runtime process connected to that project. Updates propagate to all I/O servers, clients, and web sessions.
• Local (Memory-mapped, client-only): The tag value exists in the local WindowViewer process of each client. Each client has its own independent copy and updates are not distributed.

The Show/Hide tags button is almost always implemented with one or more internal tags that store the current toggle state (for example, ViewTag, bShowTag, TagVisible). When those tags are configured as Shared, the same value is visible to all web clients and the native OS clients. The failure emerges from the following sequence:

1. User A clicks the button in a web browser tab. The shared memory tag flips to 1 and the visibility animation runs.
2. The web client re-establishes its session, or a polling cycle resets the transient UI script, and the shared tag is read back as 0 by the WindowViewer on the web host.
3. Two competing write paths (one from the button script, one from the synchronization logic on the web host) clobber the shared value, leaving the tag in an undefined state and the visibility expression evaluating to FALSE for all overlays.
4. Subsequent clicks no longer produce a visible state change because the underlying tag is being overwritten faster than the user-driven script can set it.

Native OS Clients do not exhibit the failure because each WindowViewer has its own process, and the shared tag value is only being driven by a single client at any moment. Web clients multiplex through one Web Server process, which is the conflict point.

3. InTouch Web Client Architecture

Understanding the runtime topology is required to make the fix durable.

Key architectural rules:

• Only the OS Client hosting the Web Server runs the Web Client web application. Web browsers never connect to the OS Server directly.
• The Web Server process is multiplexed: every browser tab is a logical session that reuses the same underlying WindowViewer on the Web Server host.
• Memory tags of scope Local are stored in the WindowViewer process of the client runtime. For a web session, the client runtime is the Web Server host, so all web sessions share the same Local memory unless the runtime is partitioned per session.

4. Internal Tag Scope Configuration

The fix requires that any tag used as a per-user or per-view state holder be marked Local, and that scripts reference it through the @local:: namespace.

4.1 Setting a tag to Local in WindowMaker

1. Open WindowMaker and select Special > Tagname Dictionary (or Configure > Tagname Dictionary depending on build).
2. Select the tag driving the visibility expression (typical names: View_tag, ShowTags, bTagVis).
3. In the Tag form, change Scope from Shared to Local. The field is a radio / drop-down under the tag's Type & Scope group.
4. Click Save. WindowMaker warns that Local tags are not distributed to other nodes; acknowledge.
5. Re-save the project database (the .DB file). The change only takes effect at runtime after a clean restart of WindowViewer on every client.

4.2 Referencing a Local tag from a script or animation

When the tag is Local, the script and any animation link must use the @local:: prefix, or the runtime will resolve the wrong copy and silently fall back to a zero value.

// Quick script attached to the Show/Hide tags button
// Toggles the local visibility state and re-applies it to all overlays
IF @local::View_tag == 0 THEN
   @local::View_tag = 1;
ELSE
   @local::View_tag = 0;
ENDIF;
// Force re-evaluation of the visibility expression on all selected instruments
// (select-all-in-window pattern)
INTEGER i;
FOR i = 1 TO 200 DO
   // Replace MyObjectPrefix with the user-defined animation tag prefix used
   // for the tagname visibility expression, e.g. TagVisObj01 .. TagVisObj200
   // Each object reads @local::View_tag, so the toggle is independent per session
END_FOR;

If the script is attached to a window-script or a button's Action property under On Mouse Click, the same @local:: reference must be used. Do not mix the prefix with a non-prefixed reference in the same script.

5. Step-by-Step Resolution

Prerequisites

• Full Administrator rights on the development station, the Web Server host, and the OS Server.
• InTouch development license on the engineering station.
• Read access to the project directory on the OS Server for the live .DB file.
• Stop the WindowViewer on every node before modifying the tag dictionary (to avoid the DB out of sync warning).

Procedure

1. Identify the toggle tag. Open the affected .PDL (for example @Buttons11.PDL) in WindowMaker. Inspect the button's On Mouse Click quick script and the visibility expression on the instruments. Note the tag name used as the visibility driver (typical: View_tag or ShowAllTags).
2. Change the tag scope to Local. Open Special > Tagname Dictionary, locate the tag, set Scope = Local, and save.
3. Update all references to use @local::TagName. In every script, animation link, and indirect tag reference that touches the toggle tag, prepend @local::. Use Find & Replace across all .PDL files in the project to catch orphan references (search string View_tag in WindowMaker's script editor).
4. Save and validate. In WindowMaker, run File > Validate on every .PDL that referenced the tag. A reference without the @local:: prefix produces a warning that the tag cannot be found at runtime.
5. Rebuild and re-publish. In the Publish to Web wizard, mark the modified .PDL files for incremental publish. The wizard generates the corresponding web-rendered views and the *.wdgt artifacts used by the web client. This step is required only when the affected window is in a published set.
6. Restart the Web Server host. Restart WindowViewer on the OS Client that hosts the Web Server, then restart the IIS application pool (iisreset /restart from an elevated command prompt). This forces the Web Server to load the updated .DB and the new .PDL cache.
7. Reload the browser tab. Hard refresh (Ctrl+Shift+R) every web client to clear the cached .PDL fragment.
8. Verify in native WindowViewer first. Confirm the button still works on a native OS Client connected to the OS Server, then verify on the Web Client.

6. Redundant OS Server + Single Web Server Topology

The deployment pattern matters: a single Web Server connected to a redundant pair of OS Servers is fragile because the standby OS Server does not serve web sessions, and a switchover drops the in-flight Web Client state. The supported, field-proven pattern is to install the Web Server on the OS Client that participates in the redundant pair's active view, not on a third dedicated machine.

For the recommended topology (OS Client = Web Server):

1. Install the InTouch Web Server component on the OS Client node during the InTouch setup. Select Custom and enable Web Client.
2. Configure the OS Client in the InTouch Node Properties dialog to point to the OS Server cluster. The OS Client is the redundant pair's view client; it does not host shared memory, only its Local copy.
3. Publish once from WindowMaker on the engineering station, selecting the OS Client node as the publish target. The wizard copies the published artifacts to the Web Server's InTouch Web Client publication directory.
4. Confirm IIS has a dedicated application pool for the InTouch Web Client, with Idle Timeout = 0 and Recycling disabled during operational hours. Idle timeouts reset the Web Server's in-memory state and re-introduce the same symptom.

7. Verification Procedure

After applying the fix, perform these checks before declaring the issue resolved.

1. Open the published page in two different web browsers on two different PCs. Click the Show/Hide tags button 20 times in each. Tags should toggle correctly in each browser independently of the other.
2. Open a native OS Client WindowViewer and the Web Client side by side. Toggle in one, confirm the other is unaffected (because the tag is now Local, the two runtimes no longer share the toggle state).
3. Force a redundant OS Server switchover (use the OS Server Control Panel or the engineering utility that promotes the standby). Verify the Web Client sessions reconnect within 60 s and the button still responds.
4. Inspect the InTouch diagnostic log (wwLogger.log in the InTouch install directory) for any "Tag not found", "DB out of sync", or "Tagname Dictionary mismatch" entries. The log should be free of these for the toggle tag.
5. From an elevated command prompt on the Web Server host, run iisreset /status and confirm the InTouch application pool is Started. Then run tasklist /FI "IMAGENAME eq wwindow.exe" to confirm the WindowViewer process is running on the Web Server host.
6. Re-publish the affected .PDL files from a clean state: in the Publish to Web wizard, choose Remove all, then Add all and re-publish. This clears stale cached fragments in the Web Client publication directory.

8. Troubleshooting Matrix

9. Additional Notes

For broader information on tag visibility configuration and display cues in AVEVA Plant SCADA and InTouch graphics, refer to the AVEVA documentation set on tag display and object visibility.

10. FAQ