DP44/enriched-qwen3-coder-next/Common/DTS.Common/Events/TTSImport.md

---
source_files:
  - Common/DTS.Common/Events/TTSImport/TTSImportSavedChangesStatusEvent.cs
  - Common/DTS.Common/Events/TTSImport/StatusAndProgressBarEvent.cs
  - Common/DTS.Common/Events/TTSImport/TTSImportSummaryRunTestEvent.cs
  - Common/DTS.Common/Events/TTSImport/TTSImportTestSetupChangedEvent.cs
  - Common/DTS.Common/Events/TTSImport/AssignedChannelsChangedEvent.cs
  - Common/DTS.Common/Events/TTSImport/TTSImportHardwareScanRunEvent.cs
  - Common/DTS.Common/Events/TTSImport/TTSImportSummaryImportEvent.cs
  - Common/DTS.Common/Events/TTSImport/TTSImportArmedRunTestEvent.cs
  - Common/DTS.Common/Events/TTSImport/TTSImportReadFileFinishedEvent.cs
  - Common/DTS.Common/Events/TTSImport/TTSImportHardwareScanFinishedEvent.cs
  - Common/DTS.Common/Events/TTSImport/EIDMappingEvent.cs
  - Common/DTS.Common/Events/TTSImport/TTSImportReadFileStatusEvent.cs
  - Common/DTS.Common/Events/TTSImport/TTSImportReadXMLFileEvent.cs
generated_at: "2026-04-16T03:25:22.937764+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "6b29eb45ebade668"
---

# TTS Import Event Documentation

## 1. Purpose  
This module defines a set of Prism-based events used to coordinate state and workflow across the TTS (Time-to-Sync) import process in the DTS system. These events facilitate loose coupling between UI views, view models, and business logic layers during file reading, hardware scanning, test setup configuration, and import execution. They enable asynchronous communication for steps such as file parsing, hardware channel assignment, test execution triggers, and status reporting, ensuring separation of concerns and testability.

## 2. Public Interface  

### Event Classes (all inherit from `PubSubEvent<TPayload>` unless otherwise noted):

| Event Name | Payload Type | Description |
|------------|--------------|-------------|
| `TTSImportSavedChangesStatusEvent` | `bool` | Indicates whether changes to the current TTS import setup have been saved (`true`) or not (`false`). |
| `StatusAndProgressBarEvent` | `StatusAndProgressBarEventArgs` | Updates status text and/or progress bar UI elements. *(Note: `StatusAndProgressBarEventArgs` is referenced but not defined in the provided source; its structure must be inferred from usage or defined elsewhere.)* |
| `TTSImportSummaryRunTestEvent` | `ITTSSetup` | Triggered by the Summary step to instruct the page to execute a test. |
| `TTSImportTestSetupChangedEvent` | `ITTSSetup` | Published whenever the current TTS test setup object is modified. |
| `AssignedChannelsChangedEvent` | `ITTSSetup` | Published when the set of hardware channels assigned to sensors changes. |
| `TTSImportHardwareScanRunEvent` | `ITTSSetup` | Triggered by the Hardware Scan step to initiate hardware pinging. |
| `TTSImportSummaryImportEvent` | `ITTSSetup` | Published when the user clicks the Import button in the Summary step. |
| `TTSImportArmedRunTestEvent` | `ITTSSetup` | Triggered by the Hardware Scan step to advance the workflow to the Arm step in Run Test. |
| `TTSImportReadFileFinishedEvent` | `ITTSSetup` | Published by the Read File step to signal completion of file reading. *(Note: Inherits from `CompositePresentationEvent<T>` instead of `PubSubEvent<T>`.)* |
| `TTSImportHardwareScanFinishedEvent` | `List<IDASHardware>` | Published by the page to notify the Hardware Scan view model that hardware scanning is complete, carrying the updated list of DAS hardware. |
| `EIDMappingEvent` | `IDictionary<string, string>` | Published when sensor ID to hardware channel ID mapping is determined. Key = sensor ID, Value = hardware channel ID. |
| `TTSImportReadFileStatusEvent` | `ReadFileStatusArg` | Reports success/failure of file reading. Payload contains `Status`, `TTSSetup`, and `ErrorMessage`. |
| `TTSImportReadXMLFileRequestEvent` | `TTSImportReadXMLFileRequestArg` | Request to read an XML file. Payload includes `FilePath` and `TestSetup`. |
| `TTSImportReadXMLFileResponseEvent` | `TTSImportReadXMLFileResponseEventArg` | Response to an XML read request. Payload includes `TestSetup`, `Errors`, `TTSSetup`, and `LevelTriggers`. |

### Supporting Argument Classes (defined in source):

| Class | Fields | Description |
|-------|--------|-------------|
| `ReadFileStatusArg` | `bool Status`, `ITTSSetup TTSSetup`, `string ErrorMessage` | Payload for `TTSImportReadFileStatusEvent`. `Status` indicates success; `ErrorMessage` is only meaningful when `Status == false`. |
| `TTSImportReadXMLFileRequestArg` | `string FilePath`, `ITTSSetup TestSetup` | Payload for `TTSImportReadXMLFileRequestEvent`. Used to request XML file parsing. |
| `TTSImportReadXMLLevelTrigger` | `double Threshold`, `string SensorSerialNumber` | Represents a level trigger configuration parsed from XML. |
| `TTSImportReadXMLFileResponseEventArg` | `ITestSetup TestSetup`, `string[] Errors`, `ITTSSetup TTSSetup`, `TTSImportReadXMLLevelTrigger[] LevelTriggers` | Payload for `TTSImportReadXMLFileResponseEvent`. Contains parsed data and any errors encountered. |

## 3. Invariants  

- All events use Prism’s event aggregation pattern (`PubSubEvent<T>` or `CompositePresentationEvent<T>`), implying publish-subscribe semantics: events are published once and may be subscribed to by multiple handlers.
- Events are **asynchronous** and **decoupled**; publishers do not block waiting for subscribers.
- For `TTSImportReadFileStatusEvent`, the `Status` field is the authoritative indicator of success/failure; `ErrorMessage` is only valid when `Status == false`.
- For `TTSImportReadXMLFileResponseEventArg`, `Errors` may be non-empty even if `TTSSetup` is populated (partial success).
- `EIDMappingEvent` payload is a mapping **from sensor ID to hardware channel ID**, not the reverse.
- `TTSImportReadFileFinishedEvent` uses `CompositePresentationEvent<T>` instead of `PubSubEvent<T>`, which may imply different threading or subscription behavior (e.g., thread-safe delivery, multiple subscriptions handled differently). This distinction must be respected in subscribers.

## 4. Dependencies  

### Dependencies *of* this module:
- **Prism.Events**: Core dependency for `PubSubEvent<T>` and `CompositePresentationEvent<T>`.
- **DTS.Common.Interface.TestSetups.Imports.TTS.ReadFile**: Provides `ITTSSetup`, `ITestSetup`, and related interfaces.
- **DTS.Common.Interface.DataRecorders**: Provides `IDASHardware` and `IDAS` interfaces.
- **System.Collections.Generic**: For `IDictionary<string, string>` and `List<T>`.

### Dependencies *on* this module:
- UI layers (views/view models) involved in TTS import workflow (e.g., Read File, Hardware Scan, Summary steps).
- Business logic components that process XML configuration files or manage hardware scanning.
- Any module that needs to react to test setup changes, file read results, or import progress.

## 5. Gotchas  

- **Inconsistent namespace usage**:  
  - `TTSImportTestSetupChangedEvent` and `AssignedChannelsChangedEvent` are in `DTS.Common.Events.TTSImport` namespace, while most others are in `DTS.Common.Events`. This may cause confusion during event subscription (e.g., `eventAggregator.GetEvent<TTSImportTestSetupChangedEvent>().Subscribe(...)` vs. `GetEvent<TTSImportSavedChangesStatusEvent>()`).
- **Missing definition for `StatusAndProgressBarEventArgs`**:  
  - Referenced in `StatusAndProgressBarEvent` but not defined in the provided source. Its structure (e.g., properties like `StatusText`, `ProgressValue`, `IsIndeterminate`) must be found elsewhere.
- **`TTSImportReadFileFinishedEvent` uses `CompositePresentationEvent<T>`**:  
  - This may have different semantics than `PubSubEvent<T>` (e.g., thread affinity, subscription lifetime). Subscribers must be aware of this distinction.
- **Ambiguity in `ITTSSetup` vs `ITestSetup`**:  
  - `TTSImportReadXMLFileResponseEventArg` contains both `ITestSetup` and `ITTSSetup`. It is unclear whether `ITTSSetup` is a specialized subtype of `ITestSetup` or a separate interface. Misunderstanding this could lead to incorrect casting or null dereferences.
- **No validation rules documented**:  
  - While `ReadFileStatusArg` includes `ErrorMessage`, the source does not specify what constitutes a valid `ITTSSetup` or what error conditions are expected. Validation logic (e.g., required fields in XML) is not visible here.
- **No ordering guarantees**:  
  - Events are published asynchronously. Consumers must not assume a specific order of delivery (e.g., `TTSImportTestSetupChangedEvent` may arrive before or after `AssignedChannelsChangedEvent` after a setup change).

None identified beyond the above.