DP44/enriched-qwen3-coder-next/DataPRO/Modules/TestSetups/Imports/TTS.md

---
source_files:
  - DataPRO/Modules/TestSetups/Imports/TTS/TTSImportModule.cs
generated_at: "2026-04-16T04:49:40.145713+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "1b549e2b16a3c023"
---

# TTS

### **Purpose**  
The `TTSImportModule` is a Prism module responsible for registering view and view-model types related to TTS (Test Timing Specification) import functionality within the DTS (Device Test System) framework. It enables modular UI composition by integrating TTS-specific import views (e.g., hardware scan, file editing, summary, channel configuration) into the application’s dependency injection container via Unity, making them available for navigation and reuse across the UI. This module acts as a bridge between the core test setup infrastructure and the TTS import feature set, ensuring proper instantiation and lifecycle management of its UI components.

---

### **Public Interface**  

#### **Class: `TTSImportModule`**  
- **`TTSImportModule(IUnityContainer unityContainer)`**  
  Constructor. Accepts a Unity container via dependency injection and stores it for later use in type registration during `Initialize()`.

- **`void Initialize()`**  
  Registers all TTS import-related view and view-model types as singleton mappings in the Unity container. Specifically registers:
  - `IHardwareScanView` → `HardwareScanView`
  - `IHardwareScanViewModel` → `HardwareScanViewModel`
  - `IEditFileView` → `EditFileView`
  - `IEditFileViewModel` → `EditFileViewModel`
  - `ISummaryView` → `SummaryView`
  - `ISummaryViewModel` → `SummaryViewModel`
  - `IReadFileView` → `ReadFileView`
  - `IReadFileViewModel` → `ReadFileViewModel`
  - `ILevelTriggerView` → `LevelTriggerView`
  - `ILevelTriggerViewModel` → `LevelTriggerViewModel`
  - `IAnalogChannelsView` → `AnalogChannelsView`
  - `IAnalogChannelsViewModel` → `AnalogChannelsViewModel`
  - `ITOMChannelsView` → `TOMChannelsView`
  - `ITOMChannelsViewModel` → `TOMChannelsViewModel`
  - `IDigitalInputChannelsView` → `DigitalInputChannelsView`
  - `IDigitalInputChannelsViewModel` → `DigitalInputChannelsViewModel`
  - `IDigitalOutputChannelsView` → `DigitalOutputChannelsView`
  - `IDigitalOutputChannelsViewModel` → `DigitalOutputChannelsViewModel`  

- **`void OnInitialized(IContainerProvider containerProvider)`**  
  Currently throws `NotImplementedException`. Intended for post-initialization logic per Prism module lifecycle, but unused.

- **`void RegisterTypes(IContainerRegistry containerRegistry)`**  
  Currently throws `NotImplementedException`. Presumably intended for Prism’s `IContainerRegistry`-based type registration, but not implemented.

#### **Attribute Classes**  
- **`TTSImportModuleNameAttribute`**  
  Assembly-level attribute. Inherits from `TextAttribute`. Returns `"TTSImport"` as the `AssemblyName` (via `AssemblyNames.TTSImport.ToString()`). Used to identify the module by name.

- **`TTSImportModuleImageAttribute`**  
  Assembly-level attribute. Inherits from `ImageAttribute`. Provides metadata for UI presentation:
  - `AssemblyImage`: Loads image via `AssemblyInfo.GetImage("TTSImport")`.
  - `AssemblyName`: `"TTSImport"`.
  - `AssemblyGroup`: `"Prepare"` (via `eAssemblyGroups.Prepare.ToString()`).
  - `AssemblyRegion`: `eAssemblyRegion.TTSImportRegion`.

---

### **Invariants**  
- The `TTSImportModule` must be loaded *before* any UI components that depend on its registered views/view-models are instantiated.  
- All view and view-model types registered in `Initialize()` must be concrete types implementing their respective interfaces (e.g., `HardwareScanView : IHardwareScanView`).  
- The `AssemblyNames.TTSImport` and `eAssemblyGroups.Prepare`/`eAssemblyRegion.TTSImportRegion` enums must be defined and accessible (from `DTS.Common`), or runtime failures will occur during attribute initialization.  
- The `AssemblyInfo.GetImage(...)` method must return a valid `BitmapImage` for `"TTSImport"`; otherwise, `TTSImportModuleImageAttribute` may throw or return null.

---

### **Dependencies**  
**Dependencies *of* this module:**  
- `DTS.Common` (specifically `AssemblyNames`, `eAssemblyGroups`, `eAssemblyRegion`, `AssemblyInfo`)  
- `Prism.Modularity` (`IModule`, `IContainerProvider`, `IContainerRegistry`)  
- `Unity` (`IUnityContainer`)  
- `System.Windows.Media.Imaging` (`BitmapImage`)  
- Internal interfaces under `DTS.Common.Interface.TestSetups.Imports.TTS.*` (e.g., `IHardwareScanView`, `IAnalogChannelsViewModel`)  

**Dependencies *on* this module:**  
- Any module or UI component that consumes TTS import views (e.g., via `IUnityContainer.Resolve<T>()` or Prism region navigation) depends on this module being loaded first.  
- The `TTSImportModuleNameAttribute` and `TTSImportModuleImageAttribute` are used by the host application (likely in module discovery/UI assembly rendering), so the host depends on these attributes being present.

---

### **Gotchas**  
- **`OnInitialized` and `RegisterTypes` are unimplemented** — throwing `NotImplementedException`. This is inconsistent with Prism’s `IModule` contract and may cause runtime errors if the host framework calls them.  
- **Hardcoded assembly name `"TTSImport"`** — relies on `AssemblyNames.TTSImport` and `AssemblyInfo.GetImage(...)`. If these are misconfigured or renamed, attribute initialization will fail silently or throw.  
- **No validation in `Initialize()`** — assumes all view/view-model types exist and are resolvable. Missing implementations will cause Unity registration to fail at runtime (not compile time).  
- **No cleanup logic** — the module does not unregister types or dispose resources (e.g., images), potentially contributing to memory leaks in long-running scenarios.  
- **`TTSImportModuleImageAttribute` constructor assigns `_img` twice** — redundant assignment in the parameterized constructor (`_img = ...` in both default and `: this(null)` paths). Likely harmless but indicates possible refactoring debt.  
- **No documentation on view/view-model responsibilities** — while interfaces like `IHardwareScanView` are registered, their semantics (e.g., data flow, user interactions) are not described here and must be inferred from their implementations.