Files
DP44/enriched-qwen3-coder-next/DataPRO/Modules/StatusAndProgressBar.md
2026-04-17 14:55:32 -04:00

7.2 KiB
Raw Blame History

source_files, generated_at, model, schema_version, sha256
source_files generated_at model schema_version sha256
DataPRO/Modules/StatusAndProgressBar/StatusAndProgressBarModule.cs
2026-04-16T04:28:35.090738+00:00 Qwen/Qwen3-Coder-Next-FP8 1 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 Prisms 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:

    • IStatusAndProgressBarViewStatusAndProgressBarView
    • IStatusAndProgressBarViewModelStatusAndProgressBarViewModel
    • IStatusAndProgressFooterViewStatusAndProgressFooterView
    • IStatusAndProgressBarFooterViewModelStatusAndProgressFooterViewModel
      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 assemblys 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())
    • AssemblyRegioneAssemblyRegion.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 Prisms module initialization pipeline).
  • All registered types (IStatusAndProgressBar*View, IStatusAndProgressBar*ViewModel) are registered as singletons (Prisms 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 IContainerRegistryIUnityContainer.
  • Exception handling is overly aggressive:
    Initialize() logs and rethrows only the base exceptions 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.