Configuring WindowViewer to Switch InTouch Applications at Runtime

Multi-area industrial HMI deployments frequently require operators to navigate between functionally separate InTouch applications—for example, a palletizer HMI and a conveyor HMI—without leaving the runtime environment. Closing WindowViewer to launch a different application from a desktop shortcut is operationally fragile: shortcuts are deleted, moved, or broken by Windows profile resets, and the resulting double-launch sequences force operators through two exit/relaunch cycles to return to the original screen set. This technical reference documents the three production-validated methods for switching InTouch applications from inside WindowViewer, the prerequisites for each, the security and access-control implications, and a step-by-step commissioning procedure with verification checks.

1. Overview of WindowViewer Application Switching

WindowViewer is the InTouch runtime engine that executes the WindowMaker-developed application. By design, a single WindowViewer instance loads a single InTouch application pointed to by the ApplicationDirectory entry in the Windows win.ini file, under the [Intouch] section. To swap applications without closing WindowViewer, you must either:

1. Consolidate multiple logical applications into a single InTouch project and switch between screensets at runtime.
2. Edit win.ini to repoint ApplicationDirectory and restart WindowViewer programmatically from an InTouch QuickScript or a companion process.
3. Run each InTouch application inside an isolated session (Hyper-V/VMware VM, KVM-attached PC, RDP session, or Citrix published app) and use InTouch inter-process communication or external orchestration to bring the target WindowViewer window to the foreground.

Method selection is driven by tag count, screen count, PLC count, maintenance topology, and the operator security model. For deployments with 10+ applications, each with its own Access Name and PLC network, the consolidated approach rapidly exceeds InTouch's 64,000-tag practical limit and the 32-bit addressable tag space on legacy installations, making Methods 2 or 3 the only viable options.

2. Prerequisites

Before implementing any switch-in-application strategy, validate the following prerequisites in your environment.

3. Architecture Considerations and Application Topology

Two dominant topologies appear in plant-floor deployments with multiple InTouch applications.

3.1 Terminal Services / Citrix-Hosted Model

The operator workstation is a thin client or zero client that opens an RDP or ICA session into a Windows Server. The server hosts the WindowViewer process and exposes a published InTouch app. This model is favored when PLCs sit on a plant-floor ring (e.g., DLR or PRP redundancy) that is only routable from the server VLAN. For multi-application switching, the server typically runs each InTouch app inside its own published session, and the thin client uses a session broker to launch the appropriate published app by area.

3.2 Standalone PC with Local WindowViewer

Each operator PC has a local copy of InTouch runtime and connects directly to the PLC. This is the more common model in small-to-medium plants. For switching, the consolidated or win.ini method is preferred over RDP because the operator needs the full desktop and local I/O devices (USB scales, barcode readers, hand-held scanners).

Regardless of topology, the canonical file each method manipulates is %WINDIR%\win.ini. On modern Windows versions, win.ini is preserved by Windows for backward compatibility with 16-bit applications; InTouch still reads and writes it.

4. Method 1 — Consolidated Application with Screenset Switching

The consolidated approach imports every area's windows into a single InTouch project and uses screenset navigation to move between areas at runtime. The AVEVA documentation for changing an InTouch application to an InTouchView application confirms that the InTouch Application type determines whether WindowViewer or InTouchView is the runtime host; the consolidation method works with either, but WindowViewer is the standard choice for plant-floor SCADA.

4.1 When to Choose Consolidation

• Combined tag count stays under 60,000 (16,000 on legacy 16-bit InTouch, 64,000 on 32-bit InTouch 2014 R2+).
• Combined window count stays under 1,000 unique windows (1,500 if cross-referenced with the WINDOWMAX parameter).
• PLC count is bounded (typically < 20 Access Names; you can define 256 but performance degrades above 20).
• Security model is homogeneous (all operators see all areas, or you implement $Operator permissions with discipline).

4.2 Configuration Steps

1. Open the destination InTouch application in WindowMaker.
2. From the File menu, choose Configure → WindowViewer to access the Preferences tab.
3. In the WindowViewer Startup area, set Start maximized and Show full-screen mode to control how the consolidated window opens.
4. For each subordinate application, export the windows and symbol library, then import them into the master project. Re-target the Access Names so that the master app reads from each subordinate PLC's IP.
5. Define a top-level navigation window that calls Show "MainConveyor" or Show "MainPalletizer" based on operator selection.
6. Use ActivateSecC "ConveyorView" / ActivateSecC "PalletizerView" InTouch QuickScript to switch between screensets instead of physical applications.

The detailed procedure for setting these preferences is documented in the AVEVA InTouch HMI WindowViewer configuration page.

4.3 Sample InTouch QuickScript for Consolidated Switching

// NavigateToArea.QuickScript (Button "Go to Conveyor")
// Purpose: Switches operator context to the Conveyor screenset
// Triggered: from the top-level navigation button

// Hide current main window
Hide "MainPalletizer";

// Activate the Conveyor screenset
ActivateSecC "ConveyorView";

// Show the conveyor's main window
Show "MainConveyor";

// Tag the operator's current location for audit/visibility
CurrentArea = "Conveyor";

// Force window redraw
PostMessage "MainConveyor", WM_PAINT, 0, 0;

5. Method 2 — win.ini ApplicationDirectory Switch with WindowViewer Restart

The win.ini method is the closest match to the original poster's requirement: keep each InTouch application as a separate project, then have WindowViewer reload pointing at a different directory. The win.ini approach is fully supported in InTouch 2020 R2 and 2023; AVEVA's documentation preserves the [Intouch] section for backward compatibility.

5.1 win.ini Structure

The relevant section of %WINDIR%\win.ini looks as follows:

[Intouch]
ApplicationDirectory=D:\HMIs\Palletizer
ViewOnly=0
WindowPosition=0,0,1920,1080
StartupWindow=MainPalletizer

To switch applications, a script or helper process writes a new path to ApplicationDirectory and the InTouch runtime is restarted. Because InTouch is the only consumer of this key in [Intouch], conflicts with other applications are negligible.

5.2 Sample PowerShell Helper to Switch Applications

# Switch-WindowViewerApp.ps1
# Purpose: Repoint win.ini to a new InTouch app and restart WindowViewer
# Usage:   .\Switch-WindowViewerApp.ps1 -AppPath "D:\HMIs\Conveyor"
param(
    [Parameter(Mandatory=$true)]
    [string]$AppPath
)

# 1. Verify the target application exists
if (-not (Test-Path "$AppPath\intouch.exe.view")) {
    Write-Error "InTouch application not found at $AppPath"
    exit 1
}

# 2. Stop running WindowViewer instances gracefully
Get-Process WindowViewer -ErrorAction SilentlyContinue | ForEach-Object {
    $_.CloseMainWindow() | Out-Null
    if (-not $_.WaitForExit(10000)) {
        $_.Kill()
    }
}

# 3. Update win.ini
$iniPath = "$env:WINDIR\win.ini"
$iniContent = Get-Content $iniPath -Raw

if ($iniContent -match '\[Intouch\]') {
    $iniContent = $iniContent -replace '(?ms)(\[Intouch\].*?ApplicationDirectory=).*', "`$1$AppPath"
} else {
    $iniContent += "`n[Intouch]`nApplicationDirectory=$AppPath`n"
}

Set-Content -Path $iniPath -Value $iniContent -Force

# 4. Relaunch WindowViewer
$viewerPath = "C:\Program Files\AVEVA\InTouch HMI\view.exe"
Start-Process -FilePath $viewerPath -ArgumentList "/app:$AppPath"

Write-Host "WindowViewer relaunched with application: $AppPath"

5.3 Sample InTouch QuickScript Caller

// LaunchSwitchHelper.QuickScript (Button "Go to Conveyor App")
// Purpose: Invokes the PowerShell helper from InTouch to switch apps
// Note:    Requires operator to have local admin rights on the runtime PC

string sCmd;

sCmd = "powershell.exe -ExecutionPolicy Bypass -File ";
sCmd = sCmd + '"C:\HMIs\Scripts\Switch-WindowViewerApp.ps1" ';
sCmd = sCmd + '-AppPath "D:\HMIs\Conveyor"';

StartApp sCmd;

// Optional: log the switch to the InTouch alarm log for audit
SQLInsert("AlarmLog", "OperatorAreaSwitch",
          $Operator, "Palletizer", "Conveyor", $Date, $Time);

5.4 Operational Caveats

• Process priority. WindowViewer takes 5–8 seconds to fully load a complex application. Plan operator UX around this latency.
• State loss. Any in-progress operator input, alarm acknowledgements, or recipe values in the closing WindowViewer instance are lost unless persisted to disk via the InTouch SaveTagsOnExit setting.
• License server. The license must be returned to the pool on graceful close; if the helper uses Kill(), the FlexNet heartbeat may take up to 15 minutes to release the seat.
• Antivirus interaction. Some EDR products block StartApp invocations of powershell.exe from InTouch. Add an allow-list entry or call the helper via a signed service instead.

6. Method 3 — Virtualization and Session Isolation

When the consolidated approach is impossible (too many tags) and the win.ini method is too disruptive (operator state, license, antivirus), the standard fallback is to run each InTouch application in an isolated Windows session. Four implementations are common in plant-floor environments.

6.1 Microsoft Hyper-V Virtual Machines

Each InTouch application runs inside a Windows 10 IoT Enterprise or Windows Server VM. A Hyper-V host with 64 GB RAM can host 6–8 VM sessions running small InTouch apps (under 5,000 tags each) on a single physical host. Operator UX is delivered via RDP from a thin client or via VMConnect for back-office maintenance. The VM template is sysprepped with InTouch runtime pre-installed; each VM has a fixed IP and a fixed ApplicationDirectory baked into its own win.ini.

6.2 VMware Workstation / ESXi

Functionally identical to Hyper-V but supports snapshot-based rollback, which is invaluable for managing Windows Update patching of operator stations. A snapshot taken before each InTouch application update allows the plant to roll back in under 60 seconds.

6.3 KVM Hardware Switch

Each InTouch application runs on its own physical PC. A KVM (keyboard/video/mouse) switch shares a single monitor, keyboard, and mouse across PCs. Operators select the target PC by pressing a hotkey or button on the KVM. This is the most operator-familiar model and avoids virtualization overhead, but it scales poorly beyond 4 PCs and has no central management.

6.4 Citrix Virtual Apps / Microsoft RDS Published Desktops

Each InTouch application is published as a separate Citrix app or RDS RemoteApp. The operator uses Citrix Workspace or Microsoft Remote Desktop to launch the target app. Centralized management, license pooling, and policy control make this the gold standard for large plants with 10–40+ InTouch apps.

6.5 Selection Matrix

7. Security and Access Control

Multi-application deployments must enforce which operators may access which areas. Three patterns are supported by InTouch.

7.1 $Operator Privilege Levels

InTouch's built-in $Operator system tag can carry a numeric privilege level (0–255). Combined with a custom login window that calls Login() QuickScript, you can implement role-based access. Privilege checks are typically expressed as:

// RequireAtLeast.QuickScript
// Returns 1 if the operator meets the required privilege, 0 otherwise
if ($Operator >= 200) {
    return 1;
} else {
    return 0;
}

7.2 InTouch Access Name Filtering

When consolidating, each subordinate area's Access Name should remain distinct. The application code can gate the visibility of the area's main window with a privilege check, so the operator sees only the buttons for areas they are entitled to access.

7.3 Windows User Account Control

For win.ini switching, the PowerShell helper requires local administrator rights. Grant operators a normal user account; create a separate "InTouchOperator" service account with admin rights, and configure the helper to run under that account using PsExec -u InTouchOperator -p <password> or a Windows scheduled task with stored credentials.

8. Step-by-Step Configuration: win.ini Switch Method (Detailed Procedure)

This procedure implements Method 2 and is the most direct match for the original requirement of switching between fully separate InTouch applications from inside WindowViewer.

8.1 Prepare the Runtime Environment

1. Install InTouch runtime on the operator PC. Verify the path is C:\Program Files\AVEVA\InTouch HMI\view.exe (or the Wonderware equivalent for older versions).
2. Copy each subordinate InTouch application to a dedicated folder, e.g. D:\HMIs\Palletizer, D:\HMIs\Conveyor, D:\HMIs\Filler.
3. Open WindowMaker on each application and confirm it deploys cleanly with File → Save, then File → Deploy.
4. Confirm that each application launches independently via view.exe /app:<path> from a command prompt.

8.2 Configure WindowViewer Startup Behavior

1. Open the primary InTouch application in WindowMaker.
2. From the File menu, select Configure → WindowViewer.
3. On the Preferences tab, set:
   • Start maximized = checked
   • Show window as full-screen = checked
   • Confirm exit = checked (prevents accidental loss of operator state)
4. On the Application type tab, confirm InTouch is selected (not InTouchView) to allow QuickScript execution.
5. Click OK to save.

8.3 Author the Switch Helper Script

1. Create the folder C:\HMIs\Scripts\.
2. Save the Switch-WindowViewerApp.ps1 script (shown in Section 5.2) into this folder.
3. Open an elevated PowerShell prompt and run Set-ExecutionPolicy RemoteSigned to permit locally-authored scripts.
4. Test the helper manually: .\Switch-WindowViewerApp.ps1 -AppPath "D:\HMIs\Conveyor". Verify that WindowViewer closes and reopens pointing at the Conveyor application.

8.4 Create the InTouch Switch Buttons

1. In the master application (e.g., Palletizer), open the navigation window in WindowMaker.
2. Add a button labeled "Conveyor App".
3. Configure the button's Touch Pushbuttons → Discrete action to call the QuickScript LaunchSwitchHelper with the path to the Conveyor application.
4. Repeat for each additional subordinate application.
5. Add a return-to-master button on each subordinate navigation window.

8.5 Lock Down win.ini and Configure Antivirus Exclusions

1. Open %WINDIR%\win.ini in Notepad running as administrator. Confirm the [Intouch] section contains ApplicationDirectory=D:\HMIs\Palletizer.
2. Run icacls %WINDIR%\win.ini /inheritance:r /grant:r "BUILTIN\Administrators:(M)" "InTouchOperator:(M)" "NT AUTHORITY\SYSTEM:(F)" to lock the file to administrators and the service account only.
3. In your EDR/AV product, add a process exclusion for powershell.exe when invoked from view.exe parent, scoped to the operator PC only.

9. Verification Procedure

After commissioning, validate the switch behavior with the following checks.

10. Troubleshooting Matrix

11. Long-Term Maintenance Recommendations

• Treat each subordinate InTouch application as a separately versioned artifact. Use a source control system (Git, Subversion) to tag releases; deploy with a signed installer or PowerShell DSC configuration.
• Schedule a quarterly review of win.ini on every operator PC. A drift here is the most common cause of "wrong app opens" tickets.
• Centralize the switch helper script in a read-only file share (e.g., \\corp\scripts$\InTouch\); never store the script in C:\HMIs\Scripts on each local PC, as this becomes a maintenance liability.
• For sites with more than 15 applications, evaluate migration to AVEVA System Platform with a Galaxy Repository. The Platform consolidates 10+ legacy InTouch applications into a single managed SCADA model with native area navigation, replacing all three methods documented here.
• Maintain a test-rig InTouch PC in a QA environment that mirrors the production runtime. Validate every OS patch, AV definition update, and InTouch patch against the switch helper before production rollout.

12. References and Related Documentation

The configuration procedures in this article are anchored to the following official AVEVA InTouch HMI documentation. Refer to these sources for environment-specific instructions and updated parameter lists for InTouch 2020 R2 and 2023.

• Configure general WindowViewer properties — AVEVA InTouch HMI Documentation
• Change an InTouch application to an InTouchView application — AVEVA InTouch HMI Documentation