DQMH Consortium Toolkits Feature Requests

1: Rename Helper Loop, You can rename Modules and Events, it would be nice to be able to rename helper loops.

2: There's an event under the Application Event Source called 'Application Instance Close?' that fires when the OS is shutting down or rebooting. I think this should be added to new Modules automatically to allow an orderly shutdown during unattended reboots such as when updates run.

When creating a new Event, DQMH allows us to populate the Event’s Documentation field. This documentation is then inserted into the VI documentation for that Event.

It would be very useful if the same documentation were also copied into the Control Description for the corresponding button in the API Tester.

This would allow developers to build an API Tester, provide it to a customer for quick testing, and have the tester already include helpful user-facing documentation through LabVIEW context help.

This suggestion is inspired by the following recent post in the LabVIEW Idea Exchange: Remove description of Error In and Error Out terminals 

It would be useful if the description of all error in/out terminals in all DQMH VIs was cleared (set to empty string). This would save 638 characters (0.62 KB) of disk space for each DQMH VI that uses error in/out terminals. It may help reduce EXE sizes, and may help speed up project load times and EXE build times, even if just by a fraction.

Many thanks,
Petru

I've been using cloneable modules on a regular basis. Wiring consecutive request VI calls become tedious with regards to the module ID. Having that as a pass-through makes so much more sense. This is kind of like a reference to the cloneable module if you think about it. So that wire should be treated as such on the connector pane.

I propose helper loops (HL) to register only for explicitly used events instead all cases.

Arguments:

• Improves readability: It becomes immediately clear which events the HL reacts to.
• Reduces cognitive load: No need to navigate through case structures to understand behavior.
• Enhances maintainability: Adding/removing events is more transparent and less error-prone.

This would align well with our preference for simple, explicit, and robust designs.

Currently, this is not possible, as it would break existing scripting functionality, when creating a new request, which should be handled by the HL.

By the way:Great that we have seen the scripting of the helper loop already being improved regarding...

When using the API Tester to, well, test my module, and an error occurs, I always would like to be able to clear the error indicator before moving on - just to make my life easier by being able to see clearly when new, further errors occur. 

Like this:

Is there anything at all speaking against adding this nifty little feature? 

DQMH does store some settings in the LabVIEW.ini file. For example, "The last used virtual folder for tester, virtual folder for module, and relative path on disk for module" (see WhatisNewInDQMH.html). 

I would like a Settings dialog that exposes all available settings and configurations so I

a) can learn about what's configurable
b) can switch settings easily and quickly

We could implement a "Tools -> DQMH -> Settings..." menu or add to the LabVIEW Options dialog.

Over the years I find myself adding the following two requests to my modules more and more frequently:

The MHL code for these requests is very simple, and it doesn't get in the way for modules that don't interact with subpanels. I think these requests should be added to the standard singleton and cloneable templates.

I am familiar with the "create your own module template" argument against ideas like this. I've made those same arguments before. And I've implemented my own module templates with these requests before. But present-day, I equate the utility of these subpanel functions with the utility of existing core requests like 'Show Panel', 'Hide Panel', and 'Show Diagram'.

In addition to adding these requests to the core templates, we should also add a subpanel to the API Testers to (1) be able to test these requests (obviously), and (2) demonstrate the ease with which a DQMH module can be integrated into an existing subpanel-based UI.

This typedef should be public:

Here's a thread where a DQMH user is confused by a strange code break when they use subVIs to deal with launching modules. Here's another.

This datatype necessarily occurs in wires on the block diagram when registering for broadcasts therefore it is not "really" private, and scoping it private prevents us from using subVIs to register for events. Since subVIs are the main way we segregate code and prevent block diagrams from growing without limit, it should be possible to register for events in a subVI.

We all love that DQMH has that nice small icon of an antenna which allows identification of broadcasts easily.

Why not have something similar for requests to indicate, that this VI sends a message to the module and asks it to do something?

• 
• 
• 
• ️
• 

Maybe place it to the left and use a complete different colour.

This request is focused on simplifying the block diagram, one node at a time. it seems that when receiving a request and reply, you always need to pass the current module ID back. This seems to be a very common use-case. So common that perhaps there should be a convenient Module ID indicator on the Addressed to This Module VI? The purpose of this would be to reduce the clutter and allow more space for module functionality vs framework code.

Many DQMH developers (including myself!) encounter the stumbling block of firing requests before a module is "ready". We assume that the following code is sufficient for starting and synchronizing a module:



The 'Synchronize Module Events' VI ensures that request event references are valid, but it doesn't do anything about ensuring that the module is actually ready. One very common scenario is a module Main VI that includes code in the 'Initialize' frame of the MHL that fires private events to initialize Helper Loops. If the VI that called Start Module isn't waiting on the Module Did Init broadcast, then it could immediately fire a request after calling Synchronize Module Events, and if a helper loop is registered for that event, then helper loop could run the event frame for that fired event before the MHL has had a chance to fire the private event to initialize the helper loop. There are many other possible pitfalls, but this is one of the more common ones I've seen.

To solve this issue, I think DQMH should ship with a Public API VI that is a wrapper for Start Module + Synchronize Module Events, but includes the extra step of waiting for 'Module Did Init'. The module author needs to ensure that the Module Did Init broadcast is called after all necessary initialization code... if they do so, then it is "safe" to begin calling events externally.

Here's my proposed interface for the Start Module and Wait for Initialization VI:

And my proposed implementation:

If this VI shipped with the DQMH singleton and cloneable module templates, it would help us avoid module synchronization + initialization issues like what I describe above.

It would be interesting to have the option to export the validation results from the UI with as much information as possible.

Adding the option to the CLI tool would also be interesting to create reports.

Format could be a CSV file (or HTML or PDF using the Asciidoctor toolkit ).

When renaming an event, the dialog allows you to edit the description. But it doesn't allow you to add a carriage return/newline, so you're limited in the kinds of edits you can make.

I'd like to see the ability to enter CR/LFs.

Feature request: The Add New Event dialog should always check the "add a button in the tester" Boolean by default.

Currently, it remembers whether you had it checked last time.

Reason #1: I think not adding a button is an exception, not the rule. Even though I didn't need a button last time doesn't mean that it's a pattern for how I work.

Reason #2: If you don't check it, the tester has empty events that are kind of useless until you add a button or reassign them to a different event. So you aren't saving the user any effort by not adding the button. My thinking is that it's the same amount of work to remove a button you don't want as it is to fix a broken event case.

This is a blatant copy of an idea from 2021, but it came up in a recent customer meeting.

While I agree that modifying event arguments is possible to do manually, can we take another look at automating that?

Right now if an argument is added to / removed from the typedef, it requires the developer to manually perform a series of (scriptable) actions:

1. Open the public event VI
2. Create a new control or indicator OR remove existing
3. Expand the bundle/unbundle, and wire it in OR collapse the bundle/unbundle to get rid of the deleted argument(s)
4. Wire the new item to the conpane and set it to Required (in the case of a control)
5. Update the EHL case to make sure the cluster is properly bundled (can be checked by the validator)
6. Take care of updating the Tester

So here we have a multi-step process where things could be easily forgotten. Order of operations matters. The steps are well defined. The activity is dull. It feels like a good candidate for automation.

The 'External Launch' module data for a DQMH module indicates whether or not the Main VI was started externally (True) or launched as a top-level VI (False). For the top-level VI case, the last thing that runs in your DQMH Module Main VI is the following:

I propose that we change the code to this:

When running a Main VI as a top-level EXE, it should have standard shutdown behavior.

I like the new additions to DQMH 7.1 including the Private Wait for Reply events. It's a shame however, that the feature was not fully fleshed out. It would be convenient to have the ability to convert Private Requests to Private Request and Wait for Reply.