---
source_files:
  - DataPRO/Modules/StatusAndProgressBar/StatusAndProgressBarModule.cs
generated_at: "2026-04-16T04:28:35.090738+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "cfd229ab8fa921a2"
---

# StatusAndProgressBar

## Documentation: `StatusAndProgressBarModule`

---

### **1. Purpose**

This module registers the View and ViewModel types for the status bar and progress bar UI components within a Prism-based WPF application using Unity as the DI container. It enables modular loading of the *StatusAndProgressBar* feature via Prism’s `IModule` interface, ensuring the UI components (`StatusAndProgressBarView`, `StatusAndProgressBarViewModel`, etc.) are available as singleton services in the container. Additionally, it exposes assembly-level metadata (name, image, group, region) via custom attributes (`StatusAndProgressBarPropertiesNameAttribute`, `StatusAndProgressBarPropertiesImageAttribute`) for use in UI discovery or cataloging (e.g., main screen component listing).

---

### **2. Public Interface**

#### **Class: `StatusAndProgressBarModule`**
- **Inherits**: `IModule` (Prism)
- **Constructor**:  
  `StatusAndProgressBarModule(IUnityContainer unityContainer)`  
  Injects the Unity container for type registration during initialization.

- **`void Initialize()`**  
  Registers the following types as *singleton* mappings in the Unity container:
  - `IStatusAndProgressBarView` → `StatusAndProgressBarView`
  - `IStatusAndProgressBarViewModel` → `StatusAndProgressBarViewModel`
  - `IStatusAndProgressFooterView` → `StatusAndProgressFooterView`
  - `IStatusAndProgressBarFooterViewModel` → `StatusAndProgressFooterViewModel`  
  Logs exceptions via `APILogger` and rethrows a wrapped exception.

- **`void OnInitialized(IContainerProvider containerProvider)`**  
  Currently empty; no logic implemented.

- **`void RegisterTypes(IContainerRegistry containerRegistry)`**  
  Delegates to `Initialize()` (note: despite the parameter name `containerRegistry`, the implementation uses `_unityContainer`, implying this is a legacy/compatibility shim or that `IContainerRegistry` wraps `IUnityContainer` in this context).

#### **Attribute Classes**
- **`StatusAndProgressBarPropertiesNameAttribute`**  
  - Inherits: `TextAttribute`  
  - Purpose: Exposes the assembly’s logical name for UI/cataloging.  
  - `AssemblyName` property returns `"StatusAndProgressBar"` (via `AssemblyNames.Filter.ToString()` — *note: likely a typo; should be `AssemblyNames.StatusAndProgressBar.ToString()` based on usage in `StatusAndProgressBarPropertiesImageAttribute`*).  
  - `GetAttributeType()` → `typeof(TextAttribute)`  
  - `GetAssemblyName()` → returns `AssemblyName`.

- **`StatusAndProgressBarPropertiesImageAttribute`**  
  - Inherits: `ImageAttribute`  
  - Purpose: Exposes assembly image and metadata for UI display (e.g., icon on main screen).  
  - `AssemblyImage` property returns a `BitmapImage` loaded via `AssemblyInfo.GetImage("StatusAndProgressBar")`.  
  - `AssemblyName` → `"StatusAndProgressBar"`  
  - `AssemblyGroup` → `"Viewer"` (via `eAssemblyGroups.Viewer.ToString()`)  
  - `AssemblyRegion` → `eAssemblyRegion.StatusAndProgressBarRegion`  
  - `GetAttributeType()` → `typeof(ImageAttribute)`  
  - `GetAssemblyImage()` / `GetAssemblyName()` / `GetAssemblyGroup()` / `GetAssemblyRegion()` delegate to respective properties.

---

### **3. Invariants**

- The module **must** be loaded *after* the Unity container is available (via Prism’s module initialization pipeline).
- All registered types (`IStatusAndProgressBar*View`, `IStatusAndProgressBar*ViewModel`) are registered as *singletons* (Prism’s `RegisterType` with default lifetime).
- The `AssemblyNames` enum must contain `StatusAndProgressBar` and `Filter` members; otherwise, `AssemblyInfo.GetImage(...)` or `_assemblyName` assignment may fail.
- The `AssemblyInfo.GetImage(...)` method must successfully load a `BitmapImage` for `"StatusAndProgressBar"`; otherwise, `AssemblyImage` will be `null`.
- `eAssemblyGroups.Viewer` and `eAssemblyRegion.StatusAndProgressBarRegion` must be defined in the referenced `DTS.Common` assembly.

---

### **4. Dependencies**

#### **Dependencies *of* this module:**
- **`Unity`**: For `IUnityContainer` and DI.
- **`Prism.Modularity`**: For `IModule` interface.
- **`Prism.Ioc`**: For `IContainerProvider`, `IContainerRegistry`.
- **`DTS.Common`**: For `AssemblyNames`, `AssemblyInfo`, `eAssemblyGroups`, `eAssemblyRegion`, `APILogger`.
- **`DTS.StatusAndProgressBar`**: For `IStatusAndProgressBarView`, `IStatusAndProgressBarViewModel`, etc. (note: namespace collision with local `StatusAndProgressBar` namespace — likely a separate assembly).
- **`System.Windows.Media.Imaging`**: For `BitmapImage`.
- **`System.ComponentModel.Composition`**: For `[Export]` attribute.

#### **Dependencies *on* this module:**
- Any part of the application requiring the status/progress bar UI components (e.g., main shell, viewer modules) will depend on the registered views/view models being available via DI.

---

### **5. Gotchas**

- **Critical naming inconsistency**:  
  In `StatusAndProgressBarPropertiesNameAttribute`, `_assemblyName` is set to `AssemblyNames.Filter.ToString()`, but `AssemblyNames.StatusAndProgressBar.ToString()` is used in `StatusAndProgressBarPropertiesImageAttribute`. This suggests a likely bug — `Filter` may be a typo or legacy constant. If `AssemblyNames.Filter` ≠ `"StatusAndProgressBar"`, the name attribute will expose an incorrect value.

- **Redundant/ambiguous `RegisterTypes` implementation**:  
  `RegisterTypes` calls `Initialize()`, which uses `_unityContainer` (a private field), *not* the passed `containerRegistry`. This implies either:
  - `IContainerRegistry` is a wrapper around `IUnityContainer` (and `containerRegistry` internally exposes `_unityContainer`), or
  - A design flaw where `containerRegistry` is ignored, risking registration failure if `IContainerRegistry` ≠ `IUnityContainer`.

- **Exception handling is overly aggressive**:  
  `Initialize()` logs and rethrows *only* the base exception’s string representation, discarding stack trace and inner exception details beyond logging. This may hinder debugging.

- **No cleanup logic**:  
  `StatusAndProgressBarModule` implements `IModule` but has no `Uninitialize()` or disposal logic. If the module supports hot-reloading or dynamic unloading, this may cause memory leaks.

- **Attribute usage unclear**:  
  The attributes (`StatusAndProgressBarPropertiesNameAttribute`, `StatusAndProgressBarPropertiesImageAttribute`) are applied at the *assembly* level (via `[assembly: ...]`), but their usage context (e.g., how the UI consumes them) is not documented. Their `GetAssemblyName()` methods call `AssemblyName` (a property), which may cause infinite recursion if not implemented carefully — though here they return the backing field.

- **Namespace collision**:  
  The local namespace `StatusAndProgressBar` collides with the external `StatusAndProgressBar` namespace (imported via `using StatusAndProgressBar;`). This may cause ambiguity in type resolution (e.g., `StatusAndProgressBarView` could refer to either). The code resolves this by fully qualifying external types (e.g., `StatusAndProgressBar.StatusAndProgressBarView`), but this is fragile and error-prone.

None identified from source alone beyond the above.