---
source_files:
  - Common/DTS.Common/Events/GroupTemplates/CustomChannels/CustomChannelExportFileSetEvent.cs
  - Common/DTS.Common/Events/GroupTemplates/CustomChannels/CustomChannelImportEvent.cs
generated_at: "2026-04-16T03:25:48.906062+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "7dcb7f08a2b119d1"
---

# CustomChannels

## Documentation: Custom Channel Events Module

### 1. Purpose  
This module defines Prism-based pub/sub events used to coordinate custom channel import and export operations within the application. Specifically, `CustomChannelExportFileSetEvent` signals that a custom channel export file set has been prepared (and the application should update its busy/available state accordingly), while `CustomChannelImportEvent` communicates the completion status of a custom channel import operation. These events decouple the UI and business logic layers during asynchronous custom channel workflows.

### 2. Public Interface  

- **`CustomChannelExportFileSetEvent`**  
  - *Type*: `class` inheriting from `PubSubEvent<string>`  
  - *Behavior*: A Prism event used to notify subscribers that a custom channel export file set has been generated. Despite inheriting `PubSubEvent<string>`, the event payload type is not actively used in the current implementation (see *Gotchas*). Subscribers should interpret publication of this event as a signal to mark the application as available (e.g., disable busy indicators).  

- **`CustomChannelImportEvent`**  
  - *Type*: `class` inheriting from `PubSubEvent<CustomChannelImportEventArgs>`  
  - *Behavior*: A Prism event used to notify subscribers of the completion status of a custom channel import operation. Currently only supports a single status (`Done`).  

- **`CustomChannelImportEventArgs`**  
  - *Type*: `class`  
  - *Properties*:  
    - `Status ImportStatus { get; }` – The completion status of the import operation.  
  - *Constructors*:  
    - `CustomChannelImportEventArgs(Status status)` – Initializes the args with the given `Status`.  
  - *Nested Enum*:  
    - `enum Status { Done }` – Represents possible import outcomes. Only `Done` is defined.  

### 3. Invariants  
- `CustomChannelImportEventArgs.ImportStatus` is immutable after construction (read-only property).  
- `CustomChannelImportEventArgs.Status` currently supports only one value (`Done`). No other statuses (e.g., `Failed`, `Cancelled`) are defined or used in the source.  
- `CustomChannelExportFileSetEvent` inherits from `PubSubEvent<string>`, but no payload is expected or used (see *Gotchas*).  

### 4. Dependencies  
- **Dependencies *of* this module**:  
  - `Prism.Events` (specifically `PubSubEvent<T>`).  
  - No other internal modules or types are referenced in the source files.  

- **Dependencies *on* this module**:  
  - Not specified in the provided source, but by convention, modules handling custom channel import/export workflows (e.g., UI view models, service layers) are expected to subscribe to these events.  

### 5. Gotchas  
- **Payload type mismatch in `CustomChannelExportFileSetEvent`**:  
  The class inherits from `PubSubEvent<string>`, implying a `string` payload, but the XML documentation and naming suggest it is used as a *signal* (not a data carrier). There is no evidence in the source that any subscriber expects or receives a `string` argument. This may indicate legacy or incomplete refactoring. Subscribers should treat this event as a *unit signal* (i.e., ignore the payload).  

- **Extensibility limitation in `CustomChannelImportEventArgs.Status`**:  
  The `Status` enum currently contains only `Done`. If future workflows require additional statuses (e.g., `Error`, `Cancelled`), this enum must be extended—but doing so without updating all subscribers could lead to unhandled cases.  

- **No error reporting mechanism**:  
  `CustomChannelImportEvent` only signals completion (`Done`). There is no provision for conveying error details, partial success, or cancellation. If import failures need to be communicated, a new event or extension of `CustomChannelImportEventArgs` would be required.  

- **Empty `<remarks>` sections**:  
  Neither event includes meaningful remarks in its XML documentation, suggesting minimal initial documentation effort or reliance on external design documents.