DCFG [Version 3.0]

This is the first public release of DCFG - DQMH Configuration Editor.

This release marks a fundamental shift in the DCFG architecture, designed to make it the most flexible and powerful configuration editor for all LabVIEW applications, even those not using the full DQMH framework.

Refactored the core of DCFG, replacing the main data cluster with a DCFG Wrapper Class. This change unlocks the ability to override nearly every aspect of the DCFG’s behavior while ensuring it remains simple and effective for users who just want an out-of-the-box solution.

New Features & Key Enhancements:

Class-Based Architecture: The central data cluster has been replaced by a class. This allows developers to create a child class and override methods to customize DCFG UI without modifying the core VIs.

Complete MHL Override Capability: You can now override all the Message Handling Loop (MHL) cases inside the DCFG Module. This enables powerful custom logic.

Example: You can now override the "Change View" request to add a password check or other validation logic before the view is allowed to change.

Overridable "Save Configuration" Method: The "Write to File.vi" has been renamed to "Save Configuration.vi". This VI is now a dynamic-dispatch method of the parent class. You can override it to save your configuration in any format or location you wish (e.g., database, cloud, custom binary file). The default behavior remains the same: writing the configuration as a variant to a text file.

Dynamic Class Loading at Runtime: The "DQMH_DCFG Toolkit.lvlib:Start Module.vi" now accepts an optional DCFG Wrapper Class input. The first code to call this VI "locks in" the class to be used. If no class is provided, the default DCFG class is used, ensuring "it just works" out-of-the-box.

The "DQMH_DCFG Toolkit.lvlib:Start Module.vi" takes an Options cluster to set DCFG behavior on first launch. The first code to call this VI "locks in" these features. If no Start Options is provided, the default DCFG Start Options are used.

* Start Options.Config Folder: This determines the path to where DCFG will be storing the configuration files. If left empty, the DCFG will use %LocalAppData%\DQMH Consortium\DCFG as the default directory.

* Start Options.Enable Reading Error: This determines whether errors will be reported when attempting to load an existing configuration or load a preset by name. The default value is false, where if any issues are encountered while loading the configuration, the configuration will be loaded with the default values. However, if the developer would like to get an error when there are any issues loading a file, then they should set this value to True.

* Start Options.Enable Preset: This determines whether the "Preset" section of the DCFG UI will be visible or not. The default is false, meaning the Preset section of the DCFG UI will not be visible. If the developer would like the "Preset" section to be visible on the DCFG UI, they should set this value to True.

* Start Options.Loading Conditions: This is an enumerator with the following options {Load Empty Editor, Load Editor with Existing Config Files}. The default value is "Load Empty Editor" and will ensure the DCFG Editor is empty until the developer calls the Init Config, or starts a DQMH Module that has a DCFG Configuration class. The option "Load Editor with Existing Config Files" loads the DCFG Editor with all the available configuration files in the DCFG configuration folder determined by the Config Folder above. If you want to explore this feature, create a Project from the CML with DCFG or the CML with Custom DCFG Sample Project Templates. There, you will find a VI called "CML Configuration Editor Only.vi". Please note that this setting will determine whether configuration files are deleted or not when they are removed from the DCFG.

* Start Options.Window Behavior: This is an enumerator with the following options {Floating, Floating/Auto-Hide, Modal}. The default value is "Modal".

Class-Defined Default UIs: Similar to how View UIs are handled, the default subpanel UIs are now defined in the DCFG class, allowing for easy overrides. The UIs are generated with the DCFG Scripting tool when the developer uses the Tools->DQMH Consortium->DCFG->Add DCFG Support… tools.

Refactoring & Scripting Tool Updates

These changes are crucial for standardizing the DCFG and enabling the new class-based features.

Standardized vi.lib Version: To use the DCFG Scripting Tools, developers must now use the official DQMH Consortium version of DCFG installed in vi.lib.

DCFG as a Template Option Removed: The option to select DCFG as a standalone template has been removed to consolidate efforts on the vi.lib version.

Scripting Tool Change: The scripting tools will no longer ask you to select a DCFG for scripting; they will automatically target the vi.lib version. If you want to use an override class, create a child of the DCFG Wrapper and override with your own customizationsj. An example class can found in the DCFG Example Project found in the LabVIEW Examples.

API Tester Update: The scripting tools automatically add the "Start DCFG Module.vi" to your new module’s API Tester, the buttons and code to add/remove configurations without having to run the DQMH Module.

Main DQMH Module Update: The scripting tools automatically add the required code to your DQMH Main Module. Including, creating the configuration if it has not been already initialized, and closing it only if the Module was in charge of initializing it in the first place.

olivier_jourdan , fabiola-de-la-cueva , matthiasbaudot and joerghampel were contributors to this release