noisedestroyers/DP44
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

init

Browse Source
This commit is contained in:
noisedestroyers
2026-04-17 14:55:32 -04:00
commit bc3ac1d4c9
18017 changed files with 4371742 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

71
enriched-qwen3-coder-next/Common/DTS.CommonCore/Interface/TestSetups/CachedItemsList.md Normal file
View File

@@ -0,0 +1,71 @@
---
source_files:
- Common/DTS.CommonCore/Interface/TestSetups/CachedItemsList/ICachedItemsListView.cs
- Common/DTS.CommonCore/Interface/TestSetups/CachedItemsList/ICachedItem.cs
- Common/DTS.CommonCore/Interface/TestSetups/CachedItemsList/ICachedItemsListViewModel.cs
generated_at: "2026-04-16T02:36:44.484475+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "83cb92d5e0360700"
---
# CachedItemsList
### **Purpose**
This module defines the core interfaces for a cached items list feature within the test setup infrastructure. It establishes a contract for representing and managing cached test setup items (e.g., sensors, calibrations, hardware) along with metadata about their cache state and database synchronization status. The module enables separation of concerns between view, view model, and data representation—specifically supporting UI layers that display and manage cached items while tracking freshness and completeness relative to the underlying database.
---
### **Public Interface**
#### `ICachedItemsListView : IBaseView`
- **Purpose**: Marker interface for the view layer in the cached items list feature. Extends `IBaseView`, implying it participates in a standard view/view-model pattern (likely MVVM). No additional members are defined here; implementation details are delegated to concrete view classes.
#### `ICachedItem`
- **Purpose**: Represents a single cached item with metadata about its identity, type, and synchronization state.
- **Properties**:
- `string Name { get; }` — Human-readable identifier of the item.
- `string ObjectType { get; }` — Type classification of the item (e.g., `"Sensor"`, `"Calibration"`, `"Hardware"`).
- `DateTime CacheTime { get; }` — Timestamp when the item was last cached (i.e., loaded into the cache).
- `DateTime DBTime { get; }` — Timestamp of the item’s last modification in the database. **Special semantics**: `DateTime.MinValue` indicates the item no longer exists in the database; otherwise, it reflects the `LastModified` time from the database.
#### `ICachedItemsListViewModel : IBaseViewModel`
- **Purpose**: View model responsible for managing the cached items list, updating its contents based on live data sources, and exposing state about cache validity and missing components.
- **Properties**:
- `ICachedItemsListView View { get; set; }` — Reference to the associated view; follows standard view-model binding pattern.
- `ICachedItem[] CachedItems { get; set; }` — Array of cached items currently managed by the view model.
- **Methods**:
- `bool SetCachedItems(ISensorData[] sensors, ISensorCalibration[] sensorCalibrations, IDASHardware[] hardware, IDASHardware[] allDAS)` — Updates the internal `CachedItems` array by reconciling the provided live data (`sensors`, `sensorCalibrations`, `hardware`) against the current cache. Returns `true` if the cache was successfully updated; `false` otherwise (e.g., due to invalid input or internal error).
- **Properties (read-only state indicators)**:
- `bool HasOutofDateCachedItems { get; }` — `true` if any cached item’s `DBTime` predates its `CacheTime`, indicating stale data.
- `bool HasMissingSensors { get; }` — `true` if any sensor referenced in the current setup is no longer present in the database (i.e., has `DBTime == DateTime.MinValue` in its corresponding `ICachedItem`).
---
### **Invariants**
- `ICachedItem.DBTime == DateTime.MinValue` **iff** the item is no longer present in the database.
- `ICachedItem.CacheTime` must be ≥ `ICachedItem.DBTime` for items still present in the database (i.e., `DBTime != DateTime.MinValue`).
- `ICachedItemsListViewModel.CachedItems` must be populated *only* via the `SetCachedItems` method; direct mutation of the array is discouraged (though not enforced by the interface).
- `ICachedItemsListViewModel.SetCachedItems` must compare the provided live data (`sensors`, `sensorCalibrations`, `hardware`) against `allDAS` to determine which items are obsolete or missing.
- `HasOutofDateCachedItems` and `HasMissingSensors` must be computed *based on the current `CachedItems` array* and updated after each `SetCachedItems` call.
---
### **Dependencies**
- **Depends on**:
- `DTS.Common.Base.IBaseView`, `DTS.Common.Base.IBaseViewModel` — Base interfaces for view/view-model pattern.
- `DTS.Common.Interface.DataRecorders.ISensorData`, `ISensorCalibration` — Data types for sensor and calibration records.
- `DTS.Common.Interface.Sensors.IDASHardware` — Hardware metadata interface.
- **Depended on by**:
- Concrete implementations of `ICachedItemsListView` (e.g., WPF/WinForms UI controls).
- Concrete implementations of `ICachedItemsListViewModel` (e.g., test setup logic that populates/refreshes the cached list).
- Likely consumed by higher-level test setup orchestration modules (inferred from naming and usage of `IDASHardware[] allDAS` in `SetCachedItems`).
---
### **Gotchas**
- `DBTime == DateTime.MinValue` is used as a sentinel value to indicate *deletion* from the database—not merely absence from the current cache. This is non-standard and could be confused with uninitialized timestamps.
- `SetCachedItems` accepts *four* arrays, but only `sensors`, `sensorCalibrations`, and `hardware` are used to populate the cache; `allDAS` is likely used for validation (e.g., checking if any `hardware` item is not in `allDAS`). The exact reconciliation logic is not visible here.
- The `CachedItems` property is read-write (`{ get; set; }`), implying external code *could* replace the entire array. This bypasses validation in `SetCachedItems` and may break invariants (e.g., `HasOutofDateCachedItems` may become stale).
- No explicit thread-safety guarantees are defined; concurrent access to `CachedItems` or `SetCachedItems` may cause race conditions.
- None of the interfaces expose events (e.g., `PropertyChanged`), suggesting eventing is handled via `IBaseViewModel`/`IBaseView` or external mechanisms (e.g., reactive extensions).

55
enriched-qwen3-coder-next/Common/DTS.CommonCore/Interface/TestSetups/Diagnostics.md Normal file
View File

@@ -0,0 +1,55 @@
---
source_files:
- Common/DTS.CommonCore/Interface/TestSetups/Diagnostics/IDiagnosticsTreeView.cs
- Common/DTS.CommonCore/Interface/TestSetups/Diagnostics/IDiagnosticsViewModel.cs
generated_at: "2026-04-16T02:36:28.733646+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "12ee399c3ee57cf2"
---
# Diagnostics
### 1. **Purpose**
This module defines the core interfaces (`IDiagnosticsTreeView` and `IDiagnosticsViewModel`) for a diagnostics view-model/view architecture within the test setup diagnostics subsystem. It establishes a contract for a MVVM-style pairing where `IDiagnosticsViewModel` manages the logic and state for diagnostics presentation, while `IDiagnosticsTreeView` represents the UI layer (likely a tree-structured control for displaying hierarchical diagnostic data). The interfaces extend base abstractions (`IBaseView`, `IBaseViewModel`) to integrate with a larger framework for test setup UI components.
---
### 2. **Public Interface**
#### `IDiagnosticsTreeView`
- **Signature**: `public interface IDiagnosticsTreeView : IBaseView { }`
- **Behavior**: Represents the view layer for diagnostics UI. As a marker interface extending `IBaseView`, it implies conformance to a base view contract (e.g., lifecycle, binding, or rendering responsibilities), but no additional members are defined in this source. Its purpose is to serve as a strongly-typed reference for the view in the view-model.
#### `IDiagnosticsViewModel`
- **Signature**: `public interface IDiagnosticsViewModel : IBaseViewModel`
- **Property**: `IDiagnosticsTreeView View { get; set; }`
- Gets or sets the associated view instance. Enables two-way binding or view-view-model coordination.
- **Method**: `void Unset();`
- Releases or clears the view reference (likely to break circular references, prepare for disposal, or reset state). Behavior is not further specified beyond its signature.
---
### 3. **Invariants**
- `IDiagnosticsViewModel.View` must be assignable to an instance implementing `IDiagnosticsTreeView`.
- The `Unset()` method is expected to clear or invalidate the `View` reference (e.g., set it to `null`), though the exact behavior is not specified in the source.
- Both interfaces inherit from base interfaces (`IBaseView`, `IBaseViewModel`), implying adherence to their respective contracts (e.g., lifecycle management, data binding support), but those are defined externally and not detailed here.
- *No validation rules, ordering guarantees, or state constraints are explicitly defined in the provided sources.*
---
### 4. **Dependencies**
- **Internal Dependencies**:
- `DTS.Common.Base` namespace (specifically `IBaseView` and `IBaseViewModel`).
- **External Dependencies**:
- `IDiagnosticsTreeView` and `IDiagnosticsViewModel` are likely consumed by concrete implementations (e.g., `DiagnosticsViewModel : IDiagnosticsViewModel`) and a DI/container or view-hosting layer (e.g., WPF/WinForms UI framework).
- The module is part of `DTS.CommonCore`, suggesting it is a shared dependency for test setup diagnostics components across the codebase.
- **Dependents**: Not explicitly stated, but any diagnostics UI module (e.g., a diagnostics window or panel) would depend on these interfaces for decoupled view-model binding.
---
### 5. **Gotchas**
- **Ambiguity in `Unset()` semantics**: The interface does not specify whether `Unset()` disposes resources, nullifies the `View` property, or triggers cleanup events. Implementers must infer or document this behavior.
- **No explicit event or data-binding contract**: While `IBaseViewModel` likely implies change notification (e.g., `INotifyPropertyChanged`), this is not confirmed here. Consumers should verify base interface contracts.
- **Minimal interface surface**: The interfaces are intentionally thin (likely to reduce coupling), but this means critical behavior (e.g., how diagnostics data is loaded or updated) is deferred to implementations.
- **None identified from source alone.**

49
enriched-qwen3-coder-next/Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/AnalogChannels.md Normal file
View File

@@ -0,0 +1,49 @@
---
source_files:
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/AnalogChannels/IAnalogChannelsView.cs
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/AnalogChannels/IAnalogChannelsViewModel.cs
generated_at: "2026-04-16T02:37:15.292896+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "8c6903018ff71181"
---
# AnalogChannels
### 1. Purpose
This module defines the contract for the *Analog Channels* view-model and view layers within the TTS (presumably *Test Tool Suite*) import subsystem of the test setup framework. It establishes a minimal MVVM-style separation for managing analog channel configuration UI, where `IAnalogChannelsView` represents the UI layer and `IAnalogChannelsViewModel` encapsulates the logic and state, including validation. Its role is to provide a standardized interface for binding and interaction between UI and business logic, without implementing any behavior itself—only specifying the required contract.
### 2. Public Interface
- **`IAnalogChannelsView`**
*Interface*
- Inherits from `IBaseView`.
- Serves as the contract for the view (e.g., a WPF or WinForms UI control/page) responsible for rendering analog channel configuration.
- Contains no members beyond the inherited `IBaseView` contract (not shown here).
- **`IAnalogChannelsViewModel`**
*Interface*
- Inherits from `IBaseViewModel`.
- **`IAnalogChannelsView View { get; set; }`**
Gets or sets the associated view instance. Enables two-way binding or manual view-viewmodel linking.
- **`string Validate()`**
Performs validation of the current state (e.g., user-entered analog channel settings). Returns an empty string (`""`) if valid; otherwise, returns a non-empty error message describing the first validation failure. *Note: Return type is `string`, not `bool` or `ValidationResult`—suggesting a simple, message-based validation scheme.*
### 3. Invariants
- `IAnalogChannelsView` must be assignable to `IAnalogChannelsViewModel.View`.
- `Validate()` must be idempotent and side-effect-free *with respect to state changes* (i.e., calling it multiple times should not alter the viewmodel’s internal state beyond what is implied by its return value).
- The `View` property may be `null` (not explicitly constrained), but typical usage likely requires it to be set before interaction (e.g., before calling `Validate()` or during UI initialization).
- No ordering guarantees are specified for property access (e.g., `View` may be set before or after `Validate()` calls), though conventionally the view would be assigned before validation occurs.
### 4. Dependencies
- **Depends on**:
- `DTS.Common.Base.IBaseView` and `DTS.Common.Base.IBaseViewModel` (from `DTS.Common.Base` namespace).
- **Is depended on by**:
- Likely consumed by higher-level test setup or import orchestration components (e.g., a `TTSImportManager` or similar), though not visible in the provided source.
- Concrete implementations of `IAnalogChannelsView` and `IAnalogChannelsViewModel` would reside elsewhere in the codebase (not included here).
### 5. Gotchas
- The `Validate()` method returns a `string`, but the source does not clarify whether the return value is *always* an error message (non-empty on failure, empty on success) or could include warnings/informational text. Common practice suggests the former, but this is not guaranteed.
- No documentation on thread-safety: it is unclear whether `Validate()` or `View` property access is safe to call from non-UI threads.
- `IAnalogChannelsView` and `IAnalogChannelsViewModel` are *empty contracts* beyond inheritance and the two members in the viewmodel—no data-binding properties (e.g., `ChannelCount`, `SelectedChannel`) are defined here. Actual data exposure must occur via `IBaseViewModel` or concrete implementations.
- The namespace `Imports.TTS` suggests this is part of an *import* workflow; it is unclear whether this module is also used for *export* or *configuration* scenarios.
- **None identified from source alone.**

49
enriched-qwen3-coder-next/Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/DIChannels.md Normal file
View File

@@ -0,0 +1,49 @@
---
source_files:
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/DIChannels/IDigitalInputChannelsView.cs
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/DIChannels/IDigitalInputChannelsViewModel.cs
generated_at: "2026-04-16T02:37:04.282971+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "439e5f65da5823d2"
---
# DIChannels
## 1. Purpose
This module defines the foundational view and view-model interfaces for the digital input channels section of the TTS (presumably *Test Tool Suite*) import subsystem within the DTS (Device Test System) framework. Its role is to establish a clean separation of concerns between UI representation (`IDigitalInputChannelsView`) and business logic/state management (`IDigitalInputChannelsViewModel`) using the MVVM (Model-View-ViewModel) pattern, building upon the base view/view-model abstractions (`IBaseView`, `IBaseViewModel`) provided by `DTS.Common.Base`.
## 2. Public Interface
- **`IDigitalInputChannelsView`**
*Interface*: `IDigitalInputChannelsView : IBaseView`
*Behavior*: Represents the UI layer contract for digital input channels. As a view interface, it is intended to be implemented by concrete UI components (e.g., WPF user controls, WinForms panels). It inherits `IBaseView`, implying standard view lifecycle or binding behavior (e.g., `DataContext` management), though specifics are defined in the base interface.
- **`IDigitalInputChannelsViewModel`**
*Interface*: `IDigitalInputChannelsViewModel : IBaseViewModel`
*Behavior*: Represents the view-model layer for digital input channels. It exposes a single property:
- `IDigitalInputChannelsView View { get; set; }` — A bidirectional reference to the associated view instance. This enables the view-model to interact with the view (e.g., trigger UI updates, access view-specific properties) and supports view-model-first navigation or coordination patterns.
## 3. Invariants
- `IDigitalInputChannelsView` must implement `IBaseView`.
- `IDigitalInputChannelsViewModel` must implement `IBaseViewModel`.
- The `View` property on `IDigitalInputChannelsViewModel` is *nullable* (no `required` modifier) and allows null assignment; no invariant enforces non-null state.
- No validation rules, ordering guarantees, or state constraints are specified beyond the interface hierarchy.
## 4. Dependencies
- **Depends on**:
- `DTS.Common.Base` (specifically `IBaseView`, `IBaseViewModel`)
- **Depends on by**:
- Concrete implementations of `IDigitalInputChannelsView` (e.g., UI controls)
- Concrete implementations of `IDigitalInputChannelsViewModel` (e.g., view-model classes handling DI channel data)
- Likely consumed by higher-level test setup import modules (e.g., TTS import coordinators), though not explicitly visible in this source.
## 5. Gotchas
- **Ambiguity in `View` property semantics**: The `View` property is read-write and lacks documentation. It is unclear whether:
- The view-model *owns* the view (and should dispose it),
- The view sets this reference during initialization (e.g., in its constructor or `OnLoaded`),
- Or it is used for dependency injection (e.g., by a DI container).
This could lead to circular reference issues if not managed carefully (e.g., view → view-model → view).
- **No data or command members defined**: The interfaces contain no properties, methods, or events beyond the `View` reference. All functional behavior (e.g., channel state, configuration) must be implemented in derived classes or via other mechanisms (e.g., shared models, events from `IBaseViewModel`).
- **No versioning or extensibility markers**: Absence of attributes (e.g., `[Contract]`, `[Serializable]`) or explicit versioning hints may complicate future evolution.
- **Namespace implies TTS-specific context**: The `Imports.TTS.DIChannels` path suggests this is part of a *test tool suite import* flow, not general-purpose DI channel handling—misuse outside this context could cause integration issues.
- **None identified from source alone.**

51
enriched-qwen3-coder-next/Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/DOChannels.md Normal file
View File

@@ -0,0 +1,51 @@
---
source_files:
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/DOChannels/IDigitalOutputChannelsView.cs
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/DOChannels/IDigitalOutputChannelsViewModel.cs
generated_at: "2026-04-16T02:37:33.188444+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "59f8ae955149cdda"
---
# DOChannels
### 1. **Purpose**
This module defines the core interface contracts for the digital output channels view and view model components within the TTS (likely *Test Tool Suite*) test setup import layer. It establishes the minimal contract required to integrate digital output channel UI representation (`IDigitalOutputChannelsView`) and its associated view model (`IDigitalOutputChannelsViewModel`) into the application’s MVVM (Model-View-ViewModel) architecture, leveraging the base view/view model abstractions (`IBaseView`, `IBaseViewModel`) from `DTS.Common.Base`.
### 2. **Public Interface**
- **`IDigitalOutputChannelsView`**
```csharp
public interface IDigitalOutputChannelsView : IBaseView { }
```
A marker interface representing the *view* (e.g., UI control or screen) for digital output channels. It inherits from `IBaseView`, implying it participates in the standard view lifecycle (e.g., initialization, binding, disposal), but no additional view-specific API is defined here.
- **`IDigitalOutputChannelsViewModel`**
```csharp
public interface IDigitalOutputChannelsViewModel : IBaseViewModel
{
IDigitalOutputChannelsView View { get; set; }
}
```
A view model interface for digital output channels. It exposes a single property `View` (of type `IDigitalOutputChannelsView`) that allows bidirectional linkage between the view model and its corresponding view, following a typical MVVM pattern where the view model holds a reference to its view for coordination (e.g., triggering UI updates or responding to view events). It inherits from `IBaseViewModel`, implying standard view model responsibilities (e.g., data binding, command handling, state management).
### 3. **Invariants**
- `IDigitalOutputChannelsView` must be implemented by a concrete view type that adheres to the contract of `IBaseView` (e.g., supports binding context, lifecycle events).
- `IDigitalOutputChannelsViewModel` must maintain a reference to exactly one `IDigitalOutputChannelsView` instance via its `View` property at runtime (though the property is nullable and may be `null` during initialization or teardown).
- The `View` property is read-write (`get; set;`), implying the view model is responsible for assigning or updating its associated view (e.g., during view construction or reattachment).
- No additional validation or ordering guarantees are specified (e.g., no requirement that `View` be set before certain methods are called), as the interface itself contains no methods.
### 4. **Dependencies**
- **Internal dependencies**:
- `DTS.Common.Base` (specifically `IBaseView` and `IBaseViewModel`)
- **External dependencies (inferred)**:
- Any consumer of this module (e.g., test setup configuration UI, TTS import logic) must implement or consume concrete types for `IDigitalOutputChannelsView` and `IDigitalOutputChannelsViewModel`.
- Likely depends on other TTS import modules (e.g., `TTS` namespace suggests integration with a specific test tool or framework), but no direct imports of other *types* are present in the source.
- **Depended upon by**:
- Unknown from source alone — this module provides abstractions, so concrete implementations or consumers (e.g., a view controller, DI container, or test setup builder) would reference it, but no such references are visible here.
### 5. **Gotchas**
- **No behavior defined**: Both interfaces are effectively *marker interfaces* with no methods or additional properties beyond the base contracts. Developers must infer or consult other layers (e.g., concrete implementations, tests, or documentation) for how digital output channels are actually manipulated or displayed.
- **Circular reference risk**: The `View` property on the view model creates a potential circular reference (view ↔ view model), which could lead to memory leaks or disposal issues if not managed carefully (e.g., via weak references or explicit cleanup).
- **Ambiguity in lifecycle**: Since `IBaseView`/`IBaseViewModel` behavior is not visible here, the exact timing and expectations for setting `View` (e.g., before/after binding, during construction) are unclear.
- **No data members exposed**: Despite the name "DigitalOutputChannels", the interfaces contain no properties for channel data (e.g., channel count, states, configurations). This suggests data is either handled via `IBaseViewModel` extensions or deferred to downstream implementations.

84
enriched-qwen3-coder-next/Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/EditFile.md Normal file
View File

@@ -0,0 +1,84 @@
---
source_files:
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/EditFile/IEditFileView.cs
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/EditFile/IEditFileViewModel.cs
generated_at: "2026-04-16T02:37:29.978835+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "3c042c6fc82ba63f"
---
# EditFile
## Documentation Page: `IEditFileView` and `IEditFileViewModel` Interfaces
---
### 1. **Purpose**
This module defines the contract for the *Edit File* view and view model components within the TTS (likely *Test Time Setup*) import subsystem. It supports editing of TTS channel records via a UI, with built-in validation logic—particularly for detecting duplicate channel codes among required channels—and provides UI initialization and search filtering capabilities. The interfaces follow the Model-View-ViewModel (MVVM) pattern, where `IEditFileView` represents the UI layer and `IEditFileViewModel` encapsulates presentation logic and state, inheriting from base interfaces in the `DTS.Common.Base` and `DTS.Common.Interface.TestSetups.Imports.TTS.ReadFile` namespaces.
---
### 2. **Public Interface**
#### `IEditFileView`
- **Inherits**: `IBaseView`
- **Description**: A marker interface for the view (UI) component in the Edit File flow. No additional members are defined—behavior and data binding are expected to be implemented via the associated `IEditFileViewModel`.
#### `IEditFileViewModel`
- **Inherits**: `IBaseViewModel`
- **Properties**:
- `IEditFileView View { get; set; }`
Gets or sets the associated view instance. Enables two-way binding and view coordination.
- `bool ChangeValidationIsNeeded { get; set; }`
A flag indicating whether validation should be performed on changes (e.g., user input). Likely used to defer or skip validation in certain scenarios (e.g., during initialization).
- **Methods**:
- `bool Validate()`
Performs full validation of the current state (e.g., all fields on the page). Returns `true` if valid, `false` otherwise.
- `bool ValidateChange(ITTSChannelRecord record = null)`
Validates changes made on the page. If a `record` is provided (i.e., an existing record being modified), it additionally checks for duplicate `ChannelCode` values among required channels. Returns `true` if valid, `false` otherwise.
*Note*: The `record` parameter may be `null` (e.g., for new record creation).
- `void InitializeView()`
Initializes UI components in the associated `View`. Likely populates dropdowns, binds lists, or sets initial state.
- `void Search(string text)`
Filters the available sensors (likely in a UI list or grid) based on the provided `text` (e.g., by name, code, or description).
---
### 3. **Invariants**
- `IEditFileViewModel.View` must be assigned before calling `InitializeView()` or any method that interacts with the UI (e.g., `Search()`), otherwise behavior is undefined.
- `ValidateChange(ITTSChannelRecord record)` enforces uniqueness of `ChannelCode` **only for required channels** when a non-null `record` is passed. Non-required channels may have duplicates.
- `ChangeValidationIsNeeded` controls whether validation is triggered on change events (e.g., user input), but the source does not specify *when* or *how* this flag is used internally—only that it is a configurable property.
- `Validate()` and `ValidateChange(...)` must return `false` if any validation rule fails; `true` otherwise. No exceptions are documented as part of the contract.
---
### 4. **Dependencies**
- **Internal Dependencies**:
- `DTS.Common.Base` — Provides `IBaseView` and `IBaseViewModel`, the base interfaces for UI and VM layers.
- `DTS.Common.Interface.TestSetups.Imports.TTS.ReadFile` — Defines `ITTSChannelRecord`, used in `ValidateChange`.
- **External Dependencies**:
- Any concrete implementation of `IEditFileView` must be compatible with the UI framework used (e.g., WPF, MAUI, or similar), though the interface itself is framework-agnostic.
- `ITTSChannelRecord` (from `ReadFile`) must expose at least a `ChannelCode` property and a way to identify required channels (e.g., via a `Required` flag or similar), though the exact structure is not visible here.
- **Depended Upon By**:
- Likely consumed by a concrete view model class (e.g., `EditFileViewModel`) and its corresponding view class (e.g., `EditFileView`), which are not included in this source.
---
### 5. **Gotchas**
- **Ambiguity in `ValidateChange` semantics**: The summary states it validates *changes on page*, but the parameter `record` is described as “null, or record being changed.” It is unclear whether passing `null` implies a *new* record (where duplicate checks may not apply) or an *unchanged* record (where validation may be skipped). Implementation details are required to resolve this.
- **No documentation on `ChangeValidationIsNeeded` usage**: While the property exists, the source does not specify *when* it is set to `true`/`false`, or *which methods* respect it (e.g., does `ValidateChange` skip validation when `false`?).
- **`Search` behavior unspecified**: The method filters “available sensors,” but the source does not define:
- What “available sensors” means (e.g., list of candidates, current selection, etc.).
- Whether filtering is case-sensitive or supports partial matches.
- Whether it modifies UI directly or returns filtered results.
- **No error reporting mechanism**: Both `Validate` and `ValidateChange` return only `bool`. There is no provision for returning *why* validation failed (e.g., error messages, error lists), which may require consumers to implement their own error tracking.
None identified beyond the above ambiguities.

99
enriched-qwen3-coder-next/Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/HardwareScan.md Normal file
View File

@@ -0,0 +1,99 @@
---
source_files:
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/HardwareScan/IHardwareScanView.cs
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/HardwareScan/IChannelSummary.cs
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/HardwareScan/IDasSummary.cs
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/HardwareScan/IHardwareSummaryRecord.cs
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/HardwareScan/IHardwareScanViewModel.cs
generated_at: "2026-04-16T02:37:51.896980+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "8610a74cf39a7a50"
---
# HardwareScan
## Documentation: Hardware Scan Interface Module
### 1. Purpose
This module defines the core interfaces for the *Hardware Scan* feature within the test setup import subsystem for TTS (presumably a test target system). Its role is to establish a contract between the UI (via `IHardwareScanView`) and the view model (`IHardwareScanViewModel`) that orchestrates hardware scanning operations—collecting, aggregating, and reporting hardware inventory data (e.g., DOUT, DIN, squibs, analog channels, ECMs, racks, etc.) and per-channel summaries. It enables separation of concerns by decoupling UI rendering from business logic, while providing structured data models (`IHardwareSummaryRecord`, `IChannelSummary`, `IDasSummary`) for hardware state reporting.
### 2. Public Interface
#### Interfaces
- **`IHardwareScanView : IBaseView`**
Marker interface for the view (UI layer) in the Hardware Scan feature. Inherits `IBaseView`, implying standard view lifecycle/contract (e.g., binding context, initialization). No additional members defined.
- **`IChannelSummary : IBaseClass`**
Represents a summary of channel allocation for a given channel type.
- `string ChannelType { get; set; }` – Type identifier (e.g., "DOUT", "ANALOG").
- `int Requested { get; set; }` – Number of channels requested.
- `int Assigned { get; set; }` – Number of channels assigned.
- `int Unassigned { get; set; }` – Number of channels not yet assigned.
- **`IDasSummary : IBaseClass`**
Encapsulates DAS (Data Acquisition System) hardware status.
- `string DASSerial { get; set; }` – Serial number of the DAS unit.
- `string EIDFound { get; set; }` – EID (Equipment ID) status string.
- `string BatteryVoltageStatus { get; set; }` – Battery voltage status (e.g., "OK", "LOW").
- `System.Windows.Media.SolidColorBrush BatteryVoltageColor { get; set; }` – UI color for battery status (WPF-specific).
- `string InputVoltageStatus { get; set; }` – Input voltage status.
- `System.Windows.Media.SolidColorBrush InputVoltageColor { get; set; }` – UI color for input voltage status.
- **`IHardwareSummaryRecord`**
Aggregates hardware inventory counts for a single test setup or configuration.
- `uint DOut { get; set; }` – Count of digital output channels.
- `uint DIn { get; set; }` – Count of digital input channels.
- `uint Squib { get; set; }` – Count of squib (explosive device) channels.
- `uint Analog { get; set; }` – Count of analog channels.
- `uint Total { get; }` – Read-only total of all hardware channels (`DOut + DIn + Squib + Analog + ...`).
- `uint SPS { get; set; }` – Count of SPS (presumably a subsystem/component).
- `uint SPD { get; set; }` – Count of SPD.
- `uint SPT { get; set; }` – Count of SPT.
- `uint ECM { get; set; }` – Count of ECMs (Electronic Control Modules).
- `uint Rack { get; set; }` – Count of racks.
- `uint G5 { get; set; }` – Count of G5 units.
- `void UpdateTotal()` – Recalculates and updates the `Total` property.
- `void Update(uint analog, uint squib, uint din, uint dout, uint ecm, uint sps, uint spt, uint spd, uint g5, uint rack)` – Updates all hardware counts in one call; likely triggers `UpdateTotal()` internally.
- **`IHardwareScanViewModel : IBaseViewModel`**
View model for the Hardware Scan feature. Coordinates scanning logic and data exposure.
- `IHardwareScanView View { get; set; }` – Reference to the bound view.
- `IHardwareSummaryRecord[] HardwareRecords { get; }` – Immutable array of hardware summary records (read-only).
- `void SetStatus(string status)` – Updates the UI status message (e.g., "Scanning...", "Complete").
- `void SetProgress(double progress)` – Updates progress indicator (0.0–1.0 range implied).
- `void HardwareScan()` – Initiates the hardware scan operation (synchronous or asynchronous—behavior not specified).
- `void SetChannelSummaryList(ITTSChannelRecord[] channelRecords)` – Populates channel summary data (likely used to derive `IChannelSummary` instances internally).
#### Delegates
- **`HardwareScanDelegate`**
`public delegate void HardwareScanDelegate();`
Represents a method that performs a hardware scan. Used for callback or event subscription.
### 3. Invariants
- `IHardwareSummaryRecord.Total` is a *read-only* property derived from other counts; it must be kept consistent with the sum of all individual hardware counts (`DOut`, `DIn`, `Squib`, `Analog`, `SPS`, `SPD`, `SPT`, `ECM`, `Rack`, `G5`).
- `IHardwareSummaryRecord.Update(uint...)` must ensure all provided counts are applied before `Total` is recalculated (implied by `UpdateTotal()` presence).
- `IDasSummary` properties `BatteryVoltageColor` and `InputVoltageColor` are WPF-specific (`System.Windows.Media.SolidColorBrush`), indicating this module is UI-tier dependent and not platform-agnostic.
- `HardwareRecords` is exposed as a read-only array—consumers must not modify the array contents directly.
### 4. Dependencies
- **Internal Dependencies**
- `DTS.Common.Base` namespace: `IBaseView`, `IBaseViewModel`, `IBaseClass` (base contracts for views, view models, and data classes).
- `DTS.Common.Interface.TestSetups.Imports.TTS.ReadFile`: `ITTSChannelRecord` (used in `SetChannelSummaryList`).
- `DTS.Common.Utils`: Likely contains utility types (exact usage not visible in this file).
- **External Dependencies**
- `System.Windows.Media` (for `SolidColorBrush` in `IDasSummary`), indicating a dependency on WPF.
- **Depended Upon**
- UI layer implementations (e.g., a WPF view implementing `IHardwareScanView`).
- View model implementations (e.g., concrete class implementing `IHardwareScanViewModel`).
- Likely consumed by higher-level test setup orchestration logic (e.g., a test runner or setup wizard).
### 5. Gotchas
- **WPF Coupling**: `IDasSummary` uses `System.Windows.Media.SolidColorBrush`, tightly coupling this interface to WPF. This may cause issues if reused in non-WPF contexts (e.g., headless tests, cross-platform).
- **Missing Implementation Details**:
- `HardwareScan()` behavior (synchronous vs. asynchronous, cancellation support, error handling) is not specified.
- `SetChannelSummaryList` does not expose how `ITTSChannelRecord` maps to `IChannelSummary`—implementation detail hidden.
- `HardwareRecords` is read-only, but the source does not clarify whether the underlying array is defensively copied or shared.
- **Ambiguous Acronyms**: `SPS`, `SPD`, `SPT`, `ECM`, `G5`, `DAS`, `EID` are used without definition—assumed domain-specific.
- **No Validation on `Update(uint...)`**: No indication that `Update` validates input counts (e.g., negative values, overflow).
- **No Thread Safety Contract**: `HardwareScan()` may be called from non-UI threads, but no thread-safety guarantees are documented.

90
enriched-qwen3-coder-next/Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/LevelTrigger.md Normal file
View File

@@ -0,0 +1,90 @@
---
source_files:
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/LevelTrigger/ILevelTriggerView.cs
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/LevelTrigger/ILevelTriggerViewModel.cs
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/LevelTrigger/ILevelTrigger.cs
generated_at: "2026-04-16T02:37:21.834892+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "0174d8f986cc146b"
---
# LevelTrigger
## Documentation: Level Trigger Interface Module
---
### 1. Purpose
This module defines the core interfaces for the *Level Trigger* feature within the TTS (likely *Test Trigger System*) import subsystem. It establishes the contract for modeling a level-triggered test condition—where a test action is initiated when a signal crosses a specified threshold—by abstracting the data model (`ILevelTrigger`), its view-model (`ILevelTriggerViewModel`), and view (`ILevelTriggerView`). The module serves as the foundational API layer for UI and business logic integration, enabling configuration, persistence, and runtime evaluation of level-trigger conditions in test setups.
---
### 2. Public Interface
#### `ILevelTriggerView`
- **Definition**: `public interface ILevelTriggerView : IBaseView { }`
- **Behavior**: A marker interface for the view layer of the Level Trigger feature. Inherits `IBaseView`, implying it participates in a standard MVVM (Model-View-ViewModel) pattern with base view capabilities (e.g., lifecycle, binding context). No additional members are defined here.
#### `ILevelTriggerViewModel`
- **Definition**: `public interface ILevelTriggerViewModel : IBaseViewModel`
- **Members**:
- `ILevelTriggerView View { get; set; }`
- **Behavior**: Binds the view to its view model in the MVVM pattern. The `View` property enables two-way association (e.g., for data binding or lifecycle coordination). Inherits `IBaseViewModel`, implying standard view-model responsibilities (e.g., command handling, state management).
#### `ILevelTrigger`
- **Definition**: `public interface ILevelTrigger`
- **Properties**:
- `string Code { get; }` — Unique identifier for the level trigger configuration.
- `string JCode { get; }` — Secondary identifier (possibly job- or job-step-specific).
- `double ValuePercent { get; set; }` — Threshold expressed as a percentage (e.g., of full-scale range).
- `double ValueEU { get; set; }` — Threshold expressed in engineering units (e.g., Volts, PSI).
- `string EULabel { get; }` — Human-readable label for the engineering unit (e.g., `"V"`, `"psi"`).
- `string HWSerialNumber { get; }` — Serial number of the hardware device associated with this trigger.
- `int ChannelNumber { get; }` — Logical channel number used by the trigger.
- `ITTSChannelRecord Channel { get; set; }` — The currently assigned channel record (may be `null` if unassigned).
- `ITTSSetup TestSetup { get; }` — Reference to the parent test setup containing this trigger.
- `ITTSChannelRecord[] AvailableChannels { get; }` — Read-only list of channels eligible for assignment.
- `bool IsActive { get; }` — Indicates whether the trigger is currently active (e.g., enabled in the test sequence).
- `bool IsModified { get; set; }` — Flag indicating whether the trigger configuration has unsaved changes.
- **Methods**:
- `void Refresh()` — Updates the `AvailableChannels` list and re-evaluates the `Channel` assignment (e.g., to reflect hardware changes or setup edits).
- `void Add(ITTSChannelRecord channel)` — Adds a channel to the `AvailableChannels` list and makes it eligible for assignment.
- `void Remove(ITTSChannelRecord channel)` — Removes a channel from `AvailableChannels`; if `Channel == channel`, unassigns it (sets `Channel = null`).
- `byte[] GetBytes()` — Returns a deterministic byte sequence representing the trigger’s configuration, suitable for hashing (e.g., for change detection or persistence validation).
---
### 3. Invariants
- `ChannelNumber` and `HWSerialNumber` are immutable (read-only), implying they are fixed at instantiation and tied to the hardware context.
- `AvailableChannels` must be kept consistent with the underlying hardware/test setup; modifications via `Add`/`Remove`/`Refresh` must update this array atomically.
- If `Channel` is assigned, the assigned `ITTSChannelRecord` must be present in `AvailableChannels`.
- `IsModified` is a mutable flag; its semantics imply that external consumers (e.g., UI, persistence layer) must respect its state for dirty-checking.
- `GetBytes()` must produce identical output for semantically identical configurations (i.e., deterministic serialization).
- `IsActive` is read-only, suggesting its value is controlled by external logic (e.g., test sequence state), not the trigger itself.
---
### 4. Dependencies
#### Dependencies *of* this module:
- `DTS.Common.Base` — Provides `IBaseView` and `IBaseViewModel`.
- `DTS.Common.Interface.TestSetups.Imports.TTS.ReadFile` — Defines `ITTSChannelRecord`, `ITTSSetup`, and related types (referenced but not included here).
- `System.Collections.Generic` — Used implicitly via array (`ITTSChannelRecord[]`).
#### Dependencies *on* this module:
- Any UI component implementing `ILevelTriggerView` (e.g., WPF/WinForms view).
- View-model implementations (e.g., concrete `LevelTriggerViewModel`) that bind to `ILevelTrigger`.
- Test execution logic that consumes `ILevelTrigger` to evaluate trigger conditions at runtime.
- Persistence layers that use `GetBytes()` for change tracking or serialization.
---
### 5. Gotchas
- **Ambiguity in `ChannelNumber` vs. `Channel`**: `ChannelNumber` is an `int`, while `Channel` is an `ITTSChannelRecord`. It is unclear whether `ChannelNumber` is derived from `Channel` (e.g., `Channel?.Number`) or stored separately. This may lead to inconsistencies if `Channel` is reassigned without updating `ChannelNumber`.
- **`Refresh()` semantics**: The method updates `AvailableChannels` and `Channel`, but it is unspecified whether `Channel` is reset to `null` if the current assignment is no longer in `AvailableChannels`, or whether it preserves the assignment if still valid.
- **`IsActive` mutability**: Though `IsActive` is read-only on `ILevelTrigger`, its value is likely controlled by external logic (e.g., a test sequencer). Developers must ensure synchronization between this flag and the trigger’s runtime behavior.
- **No explicit thread-safety guarantees**: The interface does not specify thread-safety for `Add`, `Remove`, or property setters (e.g., `ValuePercent`, `Channel`). Concurrent access may require external synchronization.
- **No documentation on `Code` vs. `JCode`**: The distinction between these identifiers is not explained (e.g., `Code` may be global, `JCode` job-specific), risking misuse.
*None identified from source alone.* (Note: The above are *inferred risks* based on interface design gaps—not documented behavior.)

121
enriched-qwen3-coder-next/Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/ReadFile.md Normal file
View File

@@ -0,0 +1,121 @@
---
source_files:
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/ReadFile/IReadFileView.cs
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/ReadFile/IReadFileViewModel.cs
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/ReadFile/ITTSSetup.cs
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/ReadFile/ITTSChannelRecord.cs
generated_at: "2026-04-16T02:38:21.359060+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "e7476db05b9e4a5a"
---
# ReadFile
## Documentation: TTS Read File Import Module
### 1. Purpose
This module defines the interfaces and contracts for importing TTS (Time-To-Spike) test setup configurations from external files (e.g., CSV or XML). It provides a layered architecture—comprising view, view model, and domain model interfaces—to decouple UI presentation logic from data parsing and configuration state management. The module enables loading, validating, and transforming imported file data into structured test setup objects (`ITTSSetup`, `ITTSChannelRecord`) used throughout the test execution pipeline. It supports both standard and advanced recording modes (e.g., Active RAM, Hybrid Recorder), squib channel configuration, digital I/O, and sensor-to-hardware assignment—including pre-assignment scenarios where hardware scanning occurs *after* file import.
---
### 2. Public Interface
#### Interfaces
- **`IReadFileView : IBaseView`**
A marker interface for the view layer in the TTS read-file import flow. Inherits `IBaseView`. No additional members.
- **`IReadFileViewModel : IBaseViewModel`**
View model responsible for orchestrating file import logic.
- `IReadFileView View { get; set; }` — Binds to the view instance.
- `void SetStatus(string status)` — Updates the UI status with a single message.
- `void SetStatus(string status, string error)` — Updates status *and* includes an error message.
- `void SetProgress(double progress)` — Reports import progress (0.0–1.0 range implied).
- `string FileToImport { get; set; }` — Path of the file to be imported.
- `void ReadFile(...)` — Initiates file parsing and configuration population. Parameters include:
- `fileName`: Path to the import file.
- `defaultSampleRate`, `defaultMode`, `defaultTTSPreTrigger`, `defaultTTSPostTrigger`, `defaultTTSROIStart`, `defaultTTSROIEnd`, `defaultRequireEIDFound`, `defaultDigitalInputMode`: Default values to fall back on if not present in the file.
- `squibDefaults`: `ISquibSettingDefaults` instance providing default squib fire parameters.
- **`ITTSSetup`**
Represents the parsed configuration from a TTS import file. Key properties:
- `string Filename`, `string TestId`, `string Line1`–`Line4`: Metadata (first 4 lines of CSV for edit-file reconstruction).
- `double SampleRate`, `RecordingModes Mode`, `double TestLength`, `PreTrigger`, `PostTrigger`, `ROIStart`, `ROIEnd`: Core timing and acquisition settings.
- `ITTSChannelRecord[] Channels`: Array of channel records.
- `ILevelTrigger[] LevelTriggers`: Level-trigger definitions.
- `string OriginalImportFile`: Original source file path.
- `bool AllowAdvancedRecordingModes`, `AllowActiveRecordingModes`, `AllowTSRAIRRecordingModes`: Global flags controlling supported recording modes.
- `bool RequireEIDFound`: Whether sensors without EIDs are rejected.
- `string DefaultDigitalInputMode`, `double DefaultSquibFireDurationMs`: Defaults sourced from config.
- `Tuple<string,string>[] PreAssignedSensorIdAndHwId`: Pre-mapped sensor-to-hardware IDs (used during XML import before hardware scan completes).
- `string GetHashCode()`: Custom hash code implementation (likely for change detection or caching).
- **`ITTSChannelRecord`**
Represents a single channel entry in a TTS import. Extensive properties for analog/digital/squib channels:
- `int ChannelNumber`, `string ChannelCode`, `string JCodeOrDescription`, `double ChannelRange`, `int ChannelFilterHz`: Basic channel config.
- `string SensorEID`, `SensorSerialNumber`, `SensorSensitivity`, `SensorExcitationVolts`, `SensorCapacity`, `SensorEU`, `SensorPolarity`: Sensor metadata.
- `ToyotaBridgeType ChannelType`, `string Description`, `bool ProportionalToExcitation`, `BridgeResistance`, `InitialOffsetVoltage`, `InitialOffsetVoltageTolerance`, `bool RemoveOffset`, `ToyotaZeroMethods ZeroMethod`, `CableMultiplier`, `InitialEUInMV`, `InitialEUInEU`, `IRTraccExponent`, `PolynomialConstant`, `PolynomialCoefficientC`, `PolynomialCoefficentB`, `PolynomialCoefficientA`, `PolynomialCoefficientAlpha`: Calibration and scaling parameters.
- `string ISOCode`, `ISODescription`, `ISOPolarity`: ISO-standard metadata.
- `bool IsSquib`, `bool IsDigitalInput`, `bool IsDigitalOutput`: Channel type flags.
- `bool IsEmptyRecord { get; }`: True if `ChannelCode` and `SensorSerialNumber` are both empty/null.
- `IHardwareChannel HardwareChannel { get; set; }`: Bound hardware channel (populated post-scan).
- `bool IsChannelCodeValid`, `IsJCodeValid`, `IsRangeValid`, `IsFilterValid`: Validation state flags.
- `bool Disabled`: Excludes channel from active acquisition.
- Squib-specific: `SquibFireMode`, `SquibFireDelayMs`, `LimitDuration`, `SquibFireDurationMs`, `SquibFireCurrent`, `SquibFireResistanceLowOhm`, `SquibFireResistanceHighOhm`.
- Digital I/O: `DigitalInputMode`, `DigitalOutputMode`, `DigitalOutputDelay`, `DigitalOutputDuration`.
- `IEditFileViewModel Parent { get; set; }`: Back-reference to parent edit-file view model.
- `ITTSChannelRecord Copy()`: Deep copy method.
- `Visibility RangeVisible`, `FilterVisible`: UI visibility hints (WPF `Visibility`).
- `bool OriginallyRequestedChannel`: Whether the channel was explicitly requested (vs. auto-added).
- `bool DiagnosticsMode`: Enables diagnostics mode (if supported by hardware/config).
- `bool IsModified`: Tracks whether the record has been edited.
- `byte[] GetBytes()`: Returns canonical byte representation for hashing/CRC.
#### Delegates
- **`ReadFileDelegate(string importFile)`**
Delegate signature for asynchronous or background file reading (e.g., `Task.Run` or `BackgroundWorker`). Takes the file path as input.
---
### 3. Invariants
- **`ITTSChannelRecord.IsEmptyRecord`** must be `true` *only* when both `ChannelCode` and `SensorSerialNumber` are null/empty.
- **`ITTSSetup.TestLength`** is read-only (`get;` only), implying it is derived/computed from other properties (e.g., `PreTrigger` + `PostTrigger` + ROI duration).
- **`PreAssignedSensorIdAndHwId`** is populated *only* during XML imports and is cleared once hardware assignment is finalized.
- **`AllowAdvancedRecordingModes`**, **`AllowActiveRecordingModes`**, and **`AllowTSRAIRRecordingModes`** control *global* support for advanced modes; individual channels may be invalid if these are disabled.
- **`RequireEIDFound`** enforces that sensors without EIDs are rejected *only if* this flag is `true`; otherwise, EID-less sensors may be accepted.
- **`IsModified`** on `ITTSChannelRecord` must be set to `true` after any property change that affects the output of `GetBytes()`.
---
### 4. Dependencies
#### Dependencies *of* this module:
- **`DTS.Common.Base`**: Provides `IBaseView`, `IBaseViewModel`, `IBaseClass` base interfaces.
- **`DTS.Common.Enums`**: Defines `RecordingModes`, `ToyotaBridgeType`, `ToyotaZeroMethods`, `DigitalInputModes`, `DigitalOutputModes`, `SquibFireMode`.
- **`DTS.Common.Interface.Sensors`**: Supplies `ISquibSettingDefaults` (used in `ReadFile` method).
- **`DTS.Common.Interface.DataRecorders`**: Supplies `IHardwareChannel` (used in `ITTSChannelRecord`).
- **`System.Windows`**: Used for `Visibility` type (WPF).
- **`System`**: For `Tuple<string,string>`, `delegate`, and basic types.
#### Dependencies *on* this module:
- **`ITTSSetup`** is likely consumed by:
- Test execution engine (to configure acquisition).
- UI layers (e.g., `IEditFileViewModel` via `ITTSChannelRecord.Parent`).
- Hardware scanning/assignment logic (uses `PreAssignedSensorIdAndHwId`).
- **`IReadFileViewModel`** is consumed by UI frameworks (e.g., WPF) implementing MVVM for file import workflows.
- **`ITTSChannelRecord`** is used by:
- Validation logic (via `Is*Valid` properties).
- CRC/hashing utilities (via `GetBytes()`).
- Hardware binding logic (via `HardwareChannel`).
---
### 5. Gotchas
- **`GetHashCode()` on `ITTSSetup` is explicitly declared**, suggesting a custom implementation is required—*not* inherited from `object`. This may conflict with default .NET hashing behavior if misused.
- **`PreAssignedSensorIdAndHwId`** is only populated during XML imports and is *not* persisted after hardware assignment. Relying on it post-assignment will yield incorrect results.
- **`TestLength` is read-only** (`get;` only), but its source is not defined in the interface. Its value is likely computed from `PreTrigger`, `PostTrigger`, `ROIStart`, and `ROIEnd`, but the exact formula is not specified here.
- **`IsModified`** has no setter documentation—consumers must ensure it is updated *only* when meaningful changes occur (e.g., not for UI-only state like selection).
- **`RangeVisible` and `FilterVisible`** are read-only `Visibility` properties, implying their values are computed dynamically (e.g., based on `ChannelType`). Their logic is not exposed in the interface.
- **`IsSquib`, `IsDigitalInput`, `IsDigitalOutput`** are mutually exclusive flags (implied by channel type), but the interface does not enforce this invariant—validation must occur elsewhere.
- **`DefaultDigitalInputMode`** and **`DefaultSquibFireDurationMs`** are sourced from `DataPRO.config.exe`, but the interface provides no mechanism to verify or validate these defaults. Misconfiguration here may propagate silently.
- **`ReadFile` method signature includes many defaults**, but it is unclear whether *all* parameters are required or if some may be `null`/default. For example, `squibDefaults` is typed as `ISquibSettingDefaults`, but no null-safety is documented.

97
enriched-qwen3-coder-next/Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/Summary.md Normal file
View File

@@ -0,0 +1,97 @@
---
source_files:
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/Summary/ISummaryChannel.cs
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/Summary/ISummaryView.cs
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/Summary/ISummaryViewModel.cs
generated_at: "2026-04-16T02:37:53.934971+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "b65d9ef6e313b6f0"
---
# Summary
## Documentation: Summary Module Interfaces
### 1. Purpose
This module defines core interfaces (`ISummaryChannel`, `ISummaryView`, `ISummaryViewModel`) for managing and exposing summary-level metadata and UI state related to test setup imports—specifically for TTS (likely *Test Time Series*) data. It serves as the contract layer between the view (UI), view model (business logic), and channel metadata (e.g., channel assignments, types), enabling decoupled implementation of summary views in test setup workflows. The interfaces are part of the `DTS.Common.Interface` namespace and inherit from base interfaces (`IBaseClass`, `IBaseView`, `IBaseViewModel`) in the `DTS.Common.Base` namespace.
### 2. Public Interface
#### `ISummaryChannel`
- **`string ChannelType { get; set; }`**
Gets or sets the type identifier of the channel (e.g., `"Analog"`, `"Digital"`).
- **`int Assigned { get; set; }`**
Gets or sets an integer representing the number of assigned channels.
- **`string Unassigned { get; set; }`**
Gets or sets a string representation of unassigned channel identifiers (e.g., comma-separated list or `"None"`).
#### `ISummaryView`
- **`void UpdateTestIds(string[] serializedValues)`**
Updates the view with an array of serialized test ID strings (e.g., JSON or delimited format).
- **`string GetTestId()`**
Returns the currently selected or primary test ID displayed in the view.
- **`void SetTestName(string testName)`**
Sets the test name displayed in the view.
#### `ISummaryViewModel`
- **`ISummaryView View { get; set; }`**
Gets or sets the associated view instance (MVP/MVVM pattern).
- **`void SetStatus(string status, string error = default(string))`**
Updates the UI status (e.g., progress text or error message). Optional `error` parameter allows setting an error string separately.
- **`void SetProgress(double progress)`**
Sets the current progress value (expected to be in [0.0, 1.0] range).
- **`bool TestSetupComplete { get; set; }`**
Gets or sets a flag indicating whether the test setup import process is complete.
- **`string ImportFileName { get; }`**
Gets the name of the imported file (read-only).
- **`string TestSetupName { get; }`**
Gets the user-facing name of the test setup.
- **`double SampleRate { get; }`**
Gets the sample rate (in Hz) used for the test setup.
- **`RecordingModes RecordingMode { get; }`**
Gets the recording mode (enum value from `DTS.Common.Enums.RecordingModes`).
- **`string PreTrigger { get; }`**
Gets the pre-trigger configuration (e.g., duration or condition).
- **`string PostTrigger { get; }`**
Gets the post-trigger configuration (e.g., duration or condition).
- **`void SetChannelList()`**
Triggers population or refresh of channel-related UI elements (e.g., via `ISummaryChannel` data).
- **`void UpdateUI()`**
Forces a full UI refresh.
- **`void SetSerializedTestIdValues(string[] values)`**
Sets test ID values in serialized form (likely for internal state or later retrieval).
- **`void SetAvailableSampleRates(int[] values)`**
Sets the list of available sample rates (as integers, e.g., `[1000, 5000, 10000]`).
- **`string GetTestId()`**
Returns the test ID (delegates to `ISummaryView.GetTestId()` or maintains internal state).
- **`void SetAAFExceptions(Dictionary<double, List<double>> values)`**
Sets AAF (likely *Analog Acquisition Fault*) exception data, where keys are timestamps (seconds) and values are lists of exception values (e.g., magnitudes or error codes).
### 3. Invariants
- `SampleRate`, `RecordingMode`, `PreTrigger`, `PostTrigger`, `ImportFileName`, and `TestSetupName` are **read-only** properties; their values must be set during initialization or via internal logic and not modified externally.
- `TestSetupComplete` is a mutable flag, but its semantics imply that once `true`, the test setup import process has finalized and further modifications may be disallowed (enforced by implementation, not interface).
- `progress` passed to `SetProgress` is expected to be in the range `[0.0, 1.0]`, though the interface does not enforce this.
- `SetChannelList()` and `UpdateUI()` are expected to be called *after* channel, test ID, and metadata state is updated (e.g., after `SetSerializedTestIdValues`, `SetAvailableSampleRates`, etc.).
- `SetStatus`’s `error` parameter is optional (`default(string)`), implying `status` is the primary message and `error` is secondary (e.g., for error-specific UI styling).
### 4. Dependencies
- **Depends on**:
- `DTS.Common.Base` (for `IBaseClass`, `IBaseView`, `IBaseViewModel`).
- `DTS.Common.Enums` (specifically `RecordingModes`).
- `System.Collections.Generic` (for `Dictionary<double, List<double>>`).
- `DTS.Common.Interface.TestSetups.Imports.TTS.ReadFile` (namespace reference, though no types from it are used directly in this interface—suggests a dependency on related file-reading logic).
- **Used by**:
- Implementations of `ISummaryView` (e.g., WPF/WinForms UI controls).
- Implementations of `ISummaryViewModel` (e.g., test setup import orchestrators).
- Code that consumes summary metadata (e.g., reporting, validation, or export modules).
### 5. Gotchas
- **Ambiguity in `Unassigned`**: The `string Unassigned` property lacks specification of its format (e.g., comma-separated IDs, JSON, or free text). Implementation may vary.
- **`GetTestId()` duplication**: Both `ISummaryView` and `ISummaryViewModel` expose `GetTestId()`. It is unclear whether `ISummaryViewModel.GetTestId()` delegates to `View.GetTestId()` or maintains independent state.
- **`SetSerializedTestIdValues` vs `UpdateTestIds`**: The distinction between `SetSerializedTestIdValues` (on `ISummaryViewModel`) and `UpdateTestIds` (on `ISummaryView`) is not documented. One may be internal state setter, the other UI updater.
- **`SetAAFExceptions` key/value semantics**: The meaning of `Dictionary<double, List<double>>` keys (timestamps) and values (exception lists) is not specified. Are keys absolute times? Relative? Are values magnitudes, error codes, or something else?
- **No validation guarantees**: The interface does not enforce non-null checks (e.g., `SetTestName(null)` behavior is undefined).
- **`Assigned` is `int` but `Unassigned` is `string`**: Inconsistent representation of channel assignment state may lead to parsing errors if `Unassigned` is parsed manually.
*None of the interfaces define threading model, lifecycle, or disposal semantics. Implementers must infer or document these separately.*

45
enriched-qwen3-coder-next/Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/TOMChannels.md Normal file
View File

@@ -0,0 +1,45 @@
---
source_files:
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/TOMChannels/ITOMChannelsView.cs
- Common/DTS.CommonCore/Interface/TestSetups/Imports/TTS/TOMChannels/ITOMChannelsViewModel.cs
generated_at: "2026-04-16T02:36:53.863498+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "2075bbf3b1e0d537"
---
# TOMChannels
## 1. Purpose
This module defines foundational interfaces for a Model-View-ViewModel (MVVM) pattern implementation related to TOM (likely *Test Object Model* or domain-specific test object) channel management within the test setup import subsystem for TTS (likely *Test Tool Suite*). It provides a minimal contract layer separating view and view model concerns—`ITOMChannelsView` represents the UI layer, while `ITOMChannelsViewModel` encapsulates presentation logic and state—enabling test setup configurations involving TOM channels to be tested, mocked, or swapped independently.
## 2. Public Interface
- **`ITOMChannelsView`**
*Signature:* `public interface ITOMChannelsView : IBaseView`
*Behavior:* Represents the view layer for TOM channel configuration in test setups. As a direct extension of `IBaseView`, it inherits base view contract behavior (e.g., lifecycle or binding hooks), though the source does not specify additional members. It is a marker interface with no explicit properties or methods defined here.
- **`ITOMChannelsViewModel`**
*Signature:* `public interface ITOMChannelsViewModel : IBaseViewModel`
*Behavior:* Represents the view model for TOM channel configuration. It exposes a single property `View` of type `ITOMChannelsView`, allowing bidirectional linkage between view and view model (typical in MVVM). The property is read-write (`get; set;`), implying the view model may be constructed independently and later attached to a view instance.
## 3. Invariants
- `ITOMChannelsView` must implement `IBaseView` (inherited from `DTS.Common.Base`).
- `ITOMChannelsViewModel` must implement `IBaseViewModel` (inherited from `DTS.Common.Base`).
- The `View` property of `ITOMChannelsViewModel` must be assignable and expected to hold a valid `ITOMChannelsView` instance during active use (though null assignment is not syntactically prohibited by the interface).
- No additional validation, ordering, or state constraints are specified in the source.
## 4. Dependencies
- **Depends on:**
- `DTS.Common.Base.IBaseView` (via `ITOMChannelsView`)
- `DTS.Common.Base.IBaseViewModel` (via `ITOMChannelsViewModel`)
- **Depended on by (inferred):**
- Any implementation of `ITOMChannelsView` (e.g., a WPF `UserControl`, WinForms `UserControl`, or XAML page) will depend on this interface for binding or integration with the view model.
- Any class implementing `ITOMChannelsViewModel` will depend on `IBaseViewModel` and likely on concrete view types implementing `ITOMChannelsView`.
- Other modules in `DTS.Common.Interface.TestSetups.Imports.TTS` (e.g., import logic, configuration handlers) may depend on `ITOMChannelsViewModel` to manage TOM channel settings during test setup import.
## 5. Gotchas
- The interfaces are *marker interfaces* with no explicit members beyond inheritance—behavior is entirely defined by their base interfaces (`IBaseView`, `IBaseViewModel`) and concrete implementations.
- The `View` property in `ITOMChannelsViewModel` is not initialized by the interface; callers must ensure proper view/view model pairing (e.g., via DI container or manual assignment) to avoid null reference issues.
- No documentation or naming clues indicate the purpose of "TOM channels" (e.g., whether they represent hardware channels, logical groupings, or test resources); this is domain-specific and not evident from the source.
- No versioning, obsolescence, or deprecation attributes are present—no indication of planned changes or legacy status.
- *None identified from source alone.*

181
enriched-qwen3-coder-next/Common/DTS.CommonCore/Interface/TestSetups/TestSetupsList.md Normal file
View File

@@ -0,0 +1,181 @@
---
source_files:
- Common/DTS.CommonCore/Interface/TestSetups/TestSetupsList/ITestSetupsListView.cs
- Common/DTS.CommonCore/Interface/TestSetups/TestSetupsList/ITestSetupsListViewModel.cs
- Common/DTS.CommonCore/Interface/TestSetups/TestSetupsList/ITestSetup.cs
- Common/DTS.CommonCore/Interface/TestSetups/TestSetupsList/ITestSetupRecord.cs
- Common/DTS.CommonCore/Interface/TestSetups/TestSetupsList/ITestTemplate.cs
generated_at: "2026-04-16T02:37:02.866337+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "acb65b277b35d013"
---
# TestSetupsList
## Documentation: TestSetupsList Module
---
### 1. Purpose
This module defines the core interfaces for representing, managing, and interacting with *test setups* in the DTS system. A test setup encapsulates the configuration required to execute a test—including hardware (DAS units), groups of channels, sensors, trigger conditions, and execution behavior—while supporting both persistent storage (via `ITestSetupRecord`) and runtime behavior (via `ITestSetup` and `ITestTemplate`). The module also defines UI-layer abstractions (`ITestSetupsListView`, `ITestSetupsListViewModel`) to support listing, filtering, sorting, and interaction with test setups in a view-model pattern. It serves as the foundational contract between the UI, business logic, and data persistence layers for test setup management.
---
### 2. Public Interface
#### `ITestSetupsListView`
- **Inherits**: `IBaseView`
- **Purpose**: UI view interface for the test setups list screen. No additional members—acts as a marker interface for DI/view binding.
#### `ITestSetupsListViewModel`
- **Inherits**: `IBaseViewModel`, `IFilterableListView`
- **Properties**:
- `ITestSetupsListView View { get; set; }` – Back-reference to the bound view.
- `ITestSetup[] TestSetups { get; set; }` – Current list of test setups displayed.
- **Methods**:
- `void SetTestSetups(ITestSetup[] allTestSetups)` – Replaces the current test setup list.
- `void Sort(object sortBy, bool bColumnClick)` – Sorts the displayed test setups (e.g., by name, ID).
- `void Unset()` – Clears or resets the view model state.
- `void Filter(string currentFilter)` – Filters the displayed test setups by `currentFilter` (likely name/description).
- `void MouseDoubleClick(int index)` – Handles double-click on the test setup at `index` (e.g., to open/edit).
#### `ITestSetupRecord`
- **Inherits**: *None* (base interface for persisted test setup metadata)
- **Purpose**: Represents the *data model* of a test setup stored in the database. Contains metadata, configuration flags, and trigger settings.
- **Key Properties** (selected highlights):
- `int Id`, `string Name`, `string Description`
- `bool AutomaticProgression`, `int AutomaticProgressionDelayMS`
- `RecordingModes RecordingMode`, `double SamplesPerSecondAggregate`
- `double PreTriggerSeconds`, `double PostTriggerSeconds`, `int NumberOfEvents`
- `bool StrictDiagnostics`, `bool RequireUserConfirmationOnErrors`
- `bool DoROIDownload`, `bool ViewROIDownload`, `bool DownloadAll`, `bool ViewRealtime`, `short DefaultNumberRealtimeGraphs`
- `BindingList<IRegionOfInterest> RegionsOfInterest`
- `bool Dirty`, `bool IsComplete`, `string ErrorMessage`
- `bool CheckoutMode`, `string ISFFile`, `string TestSetupUniqueId`
- Numerous trigger-related properties (e.g., `LowgLevelTriggerOnX`, `HighgLevelTriggerOnY`, etc.)
- `bool UseLabratoryDetails`, `string LabDetails`, `bool UseCustomerDetails`, `string CustomerDetails`
- `CalibrationBehaviors CalibrationBehavior`, `bool LocalOnly`, `DateTime LastModified`, `string LastModifiedBy`
- **Methods**:
- `void Copy(ITestSetupRecord copy)` – Deep copy from another record.
- `void InitializeFromDefaults(CalibrationBehaviors, RecordingModes, double preTriggerSeconds, double postTriggerSeconds, int numEvents)` – Initializes with default values.
#### `ITestSetup`
- **Inherits**: `ITestSetupRecord`
- **Purpose**: Extends `ITestSetupRecord` with runtime behavior for managing *test objects* (groups, channels, sensors, hardware).
- **Properties**:
- `Dictionary<IGroup, IGroupChannel[]> ChannelsForGroup { get; set; }`
- `Dictionary<string, bool> DASClockMasterList { get; set; }`
- `Dictionary<string, double> DASSampleRateList { get; set; }`
- `Dictionary<string, float> DASAAFRateList { get; set; }`
- `Dictionary<string, List<string>> EncapsulatedDASList { get; set; }`
- `ObservableCollection<IGroup> Groups { get; set; }`
- `int[] AddedHardware { get; set; }`, `int[] RemovedHardware { get; set; }`
- `Visibility TooltipVisibility { get; }`, `string TooltipMessage { get; }`, `string CompletionErrorMessage { get; }`
- **Methods**:
- `void AddGroup(IGroup group, IDictionary<int, ISensorData> sensorLookup, IDictionary<long, IGroupChannel> channelLookup)`
*(overload exists with `IDictionary<int, IDASHardware> hardwareLookup, IChannelSetting[] channelDefaults`)*
- `double GetSampleRate(string dasSerialNumber, double defaultValue)`
- `bool Filter(string term)` – Filters internal groups/channels by `term`.
- `int[] GetAllIncludedHardware()` – Returns hardware IDs included in the test (after additions/removals).
- `void AddHardware(int dasId, string dasSerialNumber, IDASHardware[] allHardware, IDictionary<int, IDASHardware> lookup)`
`void AddHardware(int dasId, IDictionary<int, IDASHardware> lookup)`
`void RemoveHardware(int dasId, IDASHardware[] allHardware, IDictionary<int, IDASHardware> lookup)`
- `void SaveGroups()`, `void SaveHardware()`, `void RemoveGroup(IGroup group)`
- `void MoveGroupUp(IGroup group)`, `void MoveGroupDown(IGroup group)`, `void MoveGroupToDisplayOrder(IGroup group, int displayOrder)`
- `List<IGroupChannel> GetChannels()`, `void SetTestSetupChannelOrder()`
#### `ITestTemplate`
- **Inherits**: `ITestSetup`
- **Purpose**: Represents the *heavyweight*, fully-loaded runtime instance of a test setup (e.g., `HeavyTestSetup` class). Includes UI state, derived properties, and methods for manipulation, serialization, and validation.
- **Properties** (selected highlights):
- `bool LowgLevelTriggersMixed`, `double LowgLinearLevelTriggerAggregate`, `bool HighgLevelTriggersMixed`, etc. (aggregate level trigger flags)
- `bool DestructiveTest { get; set; }` – Runtime flag indicating test is destructive/impact (affects sensor/DAS first-use date).
- `bool ExpressTestSetup`, `bool PreserveTestId`, `bool IsLoaded`, `bool QuickSensorCheck`
- `bool ArmCheckListStep`, `bool CheckListBatteryVoltageCheck`, ... (checklist step flags)
- `int ExcitationWarmupTimeMS`, `int GraphCount`, `string SetupFile`, `string TestId`, `string TestDirectory`, `string SampleRateText`
- `List<string> CheckedDASList { get; set; }`, `bool GroupsStepValid`
- `double MaxSampleRate { get; }`, `double MinSampleRate { get; }`
- `int ChannelCount { get; }`, `int IncludedChannelCount { get; }`
- **Methods** (selected highlights):
- `void CreateCopy()` – Removes IDs to create a new unsaved copy.
- `void ClearHardware()` – Clears all hardware assignments.
- `void Rename(bool bAddedGroups)` – Renames test setup and updates group references.
- `void SetGroupsListOrder()` – Sets display order based on current group list order.
- `void ReplaceLevelTriggerChannel(...)` (multiple overloads) – Updates channel IDs/group mappings in level triggers.
- `void RefreshSensorsFromDb()` – Reloads sensors from DB while preserving custom overrides.
- `void SetDisabled(string groupName, string channelName, bool disabled)` – Disables a channel (excludes from run).
- `void WriteXML(ref XmlWriter writer)` – Serializes test setup to XML.
- `void Load(bool fromDB = false)`, `void UnLoad()` – Manages memory state.
- `void LoadFromDb()`, `void UpdateFromDb()`, `IDASHardware[] GetHardwareFromDb()`, etc.
- `void CalculateIsComplete(bool bSetInDb = true)` – Computes `IsComplete` and `ErrorMessage`.
- `void MarkIsCompleteUnchecked(bool skipMemoryCheck = false)` – Sets `Dirty = true` *and* persists to DB.
- `void ReloadGroups(bool bMemoryOnly)`, `void ReloadGroupsMemoryOnly()`
- `bool CheckForIEPE()`, `bool CheckForTOM()`, `bool CheckForTOMInTest()`, `bool CheckForAnalog()`
- `double GetSampleRateForHardware(string h)`, `float GetAAFForHardware(IDASCommunication das)`, `float GetAAFForHardware(IDASCommunication das, int sps)`, `float GetRealtimeAAFForHardware(IDASCommunication idas, double samplerate)`
- `void SetHardwareOverride(string hid, bool bAdd)` – Adds/removes hardware from test.
- `void UpdateDynamicGroupFromStaticGroup(IGroup _updateGroup, IGroup staticGroup)` – Converts dynamic group to static snapshot.
- `void Rename(string newName)` – Renames the test setup.
---
### 3. Invariants
- **`ITestSetupRecord.IsComplete`** is *dependent* on `Dirty`:
If `Dirty == true`, `IsComplete` is *not* valid and must be recalculated via `CalculateIsComplete()`.
*(See `ITestSetupRecord.Dirty`, `ITestSetupRecord.IsComplete` comments)*
- **`ITestSetupRecord.ErrorMessage`** is a cached value; it is *not* automatically updated on change. Must be set explicitly (e.g., via `SetCompletionErrorMessage()` or `CalculateIsComplete()`).
- **`ITestTemplate.IsLoaded`** indicates whether full data (groups, channels, hardware) has been loaded from DB. Methods like `Load()`, `UnLoad()`, `LoadFromDb()` manage this state.
- **Hardware overrides (`AddedHardware`, `RemovedHardware`)** take precedence over hardware inferred from groups. `GetAllIncludedHardware()` reflects this.
- **Level triggers** (e.g., `LowgLevelTriggerOnX`) may reference groups/channels by ID/serial; methods like `ReplaceLevelTriggerChannel()` and `ReplaceLevelTriggerChannelGroupMapping()` exist to maintain consistency after renaming/cloning.
- **`ITestSetupRecord.LastModified`** and `LastModifiedBy` are *not* auto-updated; must be set explicitly on save.
---
### 4. Dependencies
#### Dependencies *of* this module:
- **Core Interfaces**:
- `DTS.Common.Base.IBaseView`, `DTS.Common.Base.IBaseViewModel`
- `DTS.Common.Interface.Pagination.IFilterableListView`
- `DTS.Common.Interface.Channels.IGroupChannel`
- `DTS.Common.Interface.DataRecorders.IDASHardware`, `IDASCommunication`
- `DTS.Common.Interface.Groups.GroupList.IGroup`
- `DTS.Common.Interface.Sensors.ISensorData`, `ISensorCalibration`
- `DTS.Common.Interface.RegionOfInterest.IRegionOfInterest`
- `DTS.Common.Interface.ISO.ExtraProperties.IExtraProperty`
- **Enums**:
- `DTS.Common.Enums.RecordingModes`, `DTS.Common.Enums.Sensors.CalibrationBehaviors`, `DTS.Common.Enums.DASFactory.ClockSyncProfile`, `DTS.Common.Enums.Viewer.SupportedExportFormatBitFlags`, `TimeUnitTypeEnum`, `WakeupTriggers`
- **System Types**:
- `System.Collections.Generic.*`, `System.Collections.ObjectModel.*`, `System.Collections.Specialized.BindingList<T>`, `System.Windows.Visibility`, `System.Xml.XmlWriter`
#### Dependencies *on* this module:
- UI layers (WPF) consuming `ITestSetupsListView`/`ITestSetupsListViewModel`.
- Persistence layers (DB access) implementing `ITestSetupRecord`/`ITestSetup`/`ITestTemplate`.
- Test execution engine (uses `ITestSetup`/`ITestTemplate` for runtime configuration).
---
### 5. Gotchas
- **`Dirty`/`IsComplete` state is *not* persisted automatically**:
`SetIsComplete()`, `SetIsDirty()`, and `SetCompletionErrorMessage()` only affect in-memory state. To persist, use `CalculateIsComplete(bSetInDb: true)` or `MarkIsCompleteUnchecked()` (which *does* persist `Dirty`).
- **`ITestSetupRecord` vs `ITestSetup` vs `ITestTemplate`**:
`ITestSetupRecord` is *only* for DB metadata. `ITestSetup` adds runtime group/hardware management. `ITestTemplate` is the concrete runtime implementation with full features (serialization, XML, hardware lookup, etc.). Do not assume `ITestSetup` instances are `ITestTemplate`.
- **Hardware lookup methods require external dictionaries**:
`AddHardware()`, `RemoveHardware()` require `allHardware` and `lookup` parameters—these are *not* self-contained. Callers must provide up-to-date hardware caches.
- **`DestructiveTest` is *not serialized***:
It is a runtime-only flag used during test execution (e.g., to set first-use dates).
- **`GroupsStepValid` is a UI flag**:
Set by UI logic; not computed or enforced by the interface.
- **`SampleRateText` is a string representation**:
Likely for display only; `MaxSampleRate`/`MinSampleRate` are the canonical numeric values.
- **`ITestSetupRecord.TagsBlobBytes`**:
Binary blob—interpretation is external to this module.
- **`ITestSetupRecord.LocalOnly` is deprecated**:
Comment states it is deprecated; avoid relying on it for new features.
- **`ITestTemplate.RefreshSensorsFromDb()` preserves custom values**:
Sensors are reloaded from DB, but custom overrides (range, polarity, CFC, etc.) are retained.
- **`ITestTemplate.WriteXML()` writes to an *existing* `XmlWriter`**:
Caller is responsible for creating/wrapping the writer and managing stream lifecycle.