What is New in DQMH?

DQMH 7.0 removes support for LabVIEW 2015.

There is a new Add Helper Loop to DQMH Module scripting utility available in the Tools > DQMH Consortium > DQMH > Module menu. This utility will script a new helper loop at the bottom of the diagram of the module Main VI. For more information, see here.

The Create New DQMH Event utility now allows you to create Private Request events, including Local Instance events for cloneable modules. For more details about Private Requests and Local Instance Requests, see here.

The Create New DQMH Event utility now allows you to specify which event loop in the DQMH Main VI will be registered for a new Request, Request and Wait for Reply, or Round Trip.

The Create New DQMH Event utility now provides the option to specify a custom timeout value when creating a Request and Wait for Reply or Round Trip event. (Issue #731)

For cloneable modules, when creating a new Round Trip event with the Create New DQMH Event utility, the broadcast side of the round trip now includes the Module ID of the cloneable instance that fired the broadcast. (Issue #739)

When a new request event is created with the Create New DQMH Event utility, the Module ID terminal of the request VI will now be wired in the scripted event diagram of the API Tester VI. (Issue #897)

The MHL and EHL of both modules in the DQMH Project Template have been widened by 250 pixels each. This allows for more diagram space for business logic when creating a new module from the project template, or from the 'Singleton' and 'Cloneable' entries in the Create New DQMH Event utility. Note that the width of helper module code created with the new Add Helper Loop to DQMH Module utility will match the width of the MHL.

The Validate DQMH Module utility includes a new test that detects whether or not the Static VI Reference used in the Start Module.vi matches the connector pane of the Main.vi of the module. If these don’t match, Start Module.vi will return a run-time error. (Issue #762)

The Validate DQMH Module utility includes a new test that detects the use of the Default Values:Reinitialize All To Default VI Server method on the block diagram of the module Main VI. The use of this method could inadvertently reset the values of controls passed in to the module Main VI via the Start Module VI. (Issue #838)

The Validate DQMH Module utility includes a new test that detects an improper options value wired to the Open VI Reference function in the VI Reference AE VI of a cloneable module. Cloneable modules will not function properly unless a value of 0xC0 is wired to the options input. (Issue #837)

The Validate DQMH Module utility includes updates to an existing test to improve the detection of VIs in a DQMH module with improper reentrancy settings. (Issue #836)

The Validate DQMH Module utility includes a new test to ensure the Module Name—​constant.vi has not been modified in such a way to make it incompatible with the DQMH scripting tools. (Issue #835)

The Validate DQMH Module utility includes a new test to add an Error Reported broadcast to the 'Exit' message of the module main VI’s MHL to ensure any error that occurs on module exit is sent to listeners before the module shuts down.

The Validate DQMH Module utility includes a new test to add a Module ID parameter to the Reply Payload of a cloneable Request and Wait for Reply event.

The Get DQMH Modules in Project.vi that is part of the DQMH Scripting API has been deprecated and replaced with Get DQMH Modules.vi which provides more functionality, including an optional parameter to include modules under the Dependencies node in the project. (Issue #808)

The CML Main.vi in the DQMH Continuous Measurement and Logging sample project includes buttons to launch the tester VIs of the different DQMH modules that are part of the application. (Issue #853)

The Validating an Existing DQMH Module help document now lists all the validation tests performed by the Validate DQMH Module utility.

The DQMH Style Guide was added as an option in the DQMH Tools menu. (Issue #795)

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)

When a new module is added to a project with the Add New DQMH Module utility, and the project contains auto-populating folders that match the Module and/or Tester destination folder names specified in the utility, the module and/or tester will be added directly under My Computer in the project to avoid errors, since VIs and libraries cannot be programmatically added to auto-populating folders. (Issue #785)

If you attempt to launch any of the DQMH scripting tools from a .lvlib window (i.e. with no project open), a pop-up dialog appears indicating that the tool must be launched from a project. (Issue 781)

Word wrapping is now enabled on the Module Description field of the Add New DQMH Module dialog box. (Issue #839)

The DQMH scripting tools now use a more robust mechanism for identifying framework-level virtual folders under the module library. (Issue #851)

When creating a new Request and Wait for Reply event, the reply payload cluster constant will now be created in a consistent location within the MHL, regardless of the size of the cluster. (Issue #834)

The fixer in the Validate DQMH Module utility for updating the Error Reported event frame in the tester VI was not handling some non-standard code modifications to the event diagram. The fixer is now more robust and can still script the new Error Reported event diagram contents even if there are cluster constants in the frame, and if wiring to the error tunnels has changed. (issue #873)

The fixer in the Validate DQMH Module utility for adding 'Show Module Main VI Diagram on Initialization' functionality no longer returns a 1063 error in some situations. (Issue #888)