The Private folder within the library of all DQMH template and example modules has been reorganized for easier project navigation. There are now four subfolders (Constants, Errors, Framework Support, and Typedefs) that contain all the framework-level private VIs that come with a DQMH module. You can use this organization for your own private module VIs, or create your own subfolders for business logic private subVIs. The Validate DQMH Module utility includes a new test that will optionally organize the framework-level private VIs in your existing modules to match this new design. (Issue #736)
The Status Updated broadcast was removed from the Stop Module.vi to remove ambiguity for callers in regards to when the module actually stops. The DQMH Consortium recommends callers register for the Module Did Stop broadcast to determine when a module has actually stopped. This issue is detected and can be fixed with the Validate DQMH Module utility. (Issue #819)
The Create New DQMH Event utility now scripts the MHL diagram of a new Request and Wait for Reply event in such a way to open up more whitespace to accomodate business logic code. (Issue #809)
When creating a new Broadcast event, the Create New DQMH Event utility now lists Reply Payload arguments (instead of Request arguments) when selecting the Existing Request Argument argument source.
The labels of standard error input controls on all front panels of DQMH templates and examples have been named “error in” for consistency. This includes the error input labels of newly scripted VIs such as new requests, broadcasts, etc. (Issue #782)
When creating a new module with the Add New DQMH Module utility, the library banner of the selected module template will be used as the initial banner for the new module. As with previous DQMH versions, you can then change the banner if you wish with the Edit Overlay button. (Issue #779)
The 'select a module' list ring in all DQMH scripting tools now lists modules alphabetically. (Issue #858)
The tester VIs for all DQMH templates and examples have been updated to no longer stop executing on an error condition. Instead, an error indicator on the front panel displays the most recent error that has been generated by the tester code. The Validate DQMH Module utility can identify existing testers with the old behavior and will optionally update them to the new behavior. (Issue #767)
The Main VIs for all DQMH templates and examples have been updated to include a Status Updated broadcast with a “Panel Hidden” message in the Panel Close? event when “External Launch” is TRUE. The Validate DQMH Module utility can identify existing Main VIs with the old behavior and will optionally update them to the new behavior. (Issue #738)
The Main VIs for all DQMH templates and examples have been updated to move the “error out” local variable in the “Error” frame of the MHL to be wired to the error value that was passed via the Error message. This new behavior more accurately reflects errors that occur during module execution. (Issue #803)
A comment was added to the block diagram of VI Reference AE.vi for cloneable modules explaining the intentional reference leak. (Issue #863)
The Add New DQMH Module utility now allows you to create a new module in a folder that contains a .lvproj file. (Issue #820)
The Add New DQMH Module utility now displays the module type (singleton or cloneable) in parenthesis next to the name of all source templates. (Issue #880)
The “Error” frames of the MHLs in the Main VIs for all template and example modules that ship with DQMH have been updated to contain a “DQMH_Disable_SEH==TRUE” conditional disable structure that wraps the Simple Error Handler VI call. This is to allow the developer to prevent the Simple Error Handler from being loaded when the module is loaded, which is useful for some situations, such as deploying a module to a Real-Time target. (Issue #844)
All DQMH module framework VIs (i.e. VIs and CTLs included in every DQMH module) have been updated to have internal tagging identifying them as framework VIs. This improves the reliability of the DQMH Scripting Tools. There is also a new test in the Validate DQMH Module tool that will detect untagged (or incorrectly tagged) framework VIs and add proper tags to them. (Issue #902)
The Validate DQMH Module utility now pops up a warning dialog if your project contains any DQMH modules with unsaved changes. This makes the Validate DQMH Module utility consistent with other DQMH Scripting Tools. (Issue #905)