DQMH Consortium Toolkits Feature Requests

Loving the latest Validation tool, but I found a few improvements.  Putting it all here in one feature request for now.

1. Make Validation issues sortable by issue
   Background: I recently ran the validation over an old application (DQMH 5).  It seemed to sort things by VI.  It would be nice to be able to sort the list by issue, so that you can easily tick off each issue one at a time.  You can do that at the moment by multiple clicking separate lines, but it would be nicer if it was grouped together.

2. Put a tip somewhere on the panel: "Tip: Double click a row to show the issue." 

3. Double click didn't seem to work every time.  I tried it on a few issues, and nothing seemed to open or do anything.

4. Display a warning dialog after the Fix All Issues button is pressed.  I accidentally pressed Fix All Issues instead of Fix Selected Issues, and it just blazed away.  Suggest a dialog: "This will fix all issues listed here.  Do you want to continue?"

5. Fix All Issues button location - I prefer to use Fix Selected Issues, and it's so tempting to just press Fix All Issues.  Not sure what the answer is here, but perhaps Fix Selected Issues should be where Fix All Issues button is.  This is probably quite subjective. If we implement previous suggestion, then this may not matter as much.

6. Where an issue will actually potentially delete/remove code from an existing VI, I suggest rather than a "Note:" description, separate the text and call it a "Warning" or something similar, and colour in red if possible so that it stands out. I can't remember which issue this was related to sorry, but it was only one issue.

7. When we get this:
The block diagram of RT Event Logger.lvlib:Main.vi contains a Register For Events function labeled "DQMH_REG_EVENTS". The source of the RT Event Logger Request Events terminal on this function is named "Event Logger Request Events". In order for the DQMH scripting tools to work correctly, change the source of this wire (usually a subVI output or a user event constant) to have a label of "RT Event Logger Request Events" instead.

This information was redundant by the time I'd already fixed the sub VI.  Perhaps add an extra note to this description: "Note: This may become automatically resolved by addressing the associated Sub VI" or something to that affect.

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.

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.

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.

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 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.

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.

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.

Improvement 1

It would be useful to be able to  remove multiple events of the same module in one operation. Currently only one event can be removed at a time.

Motivation: Just now I found myself having to remove four request events from a DQMH module. This involved launching the "Remove DQMH Event" window four times. This was slightly tedious due to:

• Having to navigate the relatively deeply nested menu four times (Tools > DQMH Consortium > DQMH > Event > Remove DQMH Event...).
• Having to wait for the dialogue to load four times. I'm working with a large codebase. This is the single slowest step for me at the moment. Using the Stopwatch functionality of the Windows Clock app I timed this load time at around 9 seconds. I took a single measurement. I have a feeling that the dialogue took longer than 9 seconds to load in the past (perhaps as much as 15 or 20 seconds).

Idea expansion:

• It might be useful to be able to delete multiple events that belong to multiple modules in one operation. This would be the most general form of the Remove operation. This is probably not a common use case, but people would find it useful every now and then.

Improvement 2

Currently the files associated with the event (the request VI, the CTL argument) are permanently deleted. It would be useful if there was a global setting that would make the deleted files go to the Recycle Bin (instead of being permanently deleted).

The excellent Delete File From Project by BasvE tool (https://www.vipm.io/package/basve_lib_lvdeletefile/) implements this functionality (global setting to dictate whether files are permanently deleted or sent to Recycle Bin).

When the DQMH Consortium introduced the support for private requests with DQMH 7.0, a conscious decision was made not to support synchronous requests with reply, to avoid dead-lock scenarios.

With the way we at HSE start additional DQMH modules from any given DQMH module (by sending a request from the MHL to the EHL to start and register for modules, then reply back to the calling MHL case, so the whole process becomes synchronous), it would be super helpful if we could script those private "start submodule" requests the exact same way as all other private requests.

TL;DR: Add support for private Request and Wait for Reply.

Edit: After internal discussion, let me add that I know how to make a regular request a private one by setting the access scope. I don’t want to do that - I want the private Request with Reply to be the same as all other private events, and not a modified public request.

Edit2: If you scroll down, you'll see that Manu added a vital piece of information. We usually communicate with one of the EHLs/Helper Loops, not the MHL. So scripting should not create another case in the MHL but keep the reply in the targeted EHL/Helper Loop.

I’d like to suggest making the DQMH scripting tools API public. This would allow new events or modules to be generated programmatically.

My use case: I’d like to take any non-DQMH library and generate a DQMH layer for the library’s public API. With some clever coding and discipline, this could automate the creation of a TestStand API based on DQMH, which would be incredibly useful.

Moreover, public APIs often encourage the development of supporting tools and promote the technology, especially within creative communities.

When creating a new Event, it would be empowering to be able to automatically call a VI immediately after the scripting completes. The idea is based on the behavior of the Pre- and Post-Build VI calling ability of the application build process. The implementation should provide an option to specify a VI to call and an option to generate a VI with the proper controls already on the connector pane. A proposed set of such controls would be VI references or paths to the Event VI or VIs (Broadcast or Request... or both for Round Trip) and VI references or paths to the Tester VI and RT Tester VI (if there is one).

Adding the feature would allow developers using DQMH to create their own extensions to the built-in scripting. For example, if the other feature request here is not accepted, this one would allow a developer to implement it on our own.

Any reason not to?

Today DQMH scripters add comments with specific hashtags. But some of these hashtags names are very generic (for example #CodeNeeded or #CodeRecommended).

Adding a 'DQMH_' prefix would allow a better isolation of DQMH related hashtags in the bookmark manager (ie. #DQMH_CodeNeeded).

Actually some DQMH tags already have this prefix (#DQMH_HowTo).

When creating a new DQMH event, I'd like this

Well, it is a corner case, but I somehow ran into the situation, that the xml metadata at <LabVIEW Data>\DQMH Module Templates\ defined a name for the API tester which was not correct, resulting in an error 7 message

Please add the path, which the scripting is trying to copy to the message, as a first hint.

Adding a note to check the XML would be a second nice hint for the user.

Offtopic: Lastly, I wonder, why the name of the API Tester needs to be present in the XML at all. I was expecting that the module validation fails, if the tester doesn't match the naming rule, which is also applied, when a module is being renamed. A quick test shows, that my assumption is not correct: The API Tester of a module can be named randomly. I am pretty sure, I have applied Fixes to API Testers via the validation dialogue in the past and I wonder how that works, if the naming rule is not required 🤔

When adding an helper loop from the scripter, add a checkbox that would allow creating a subVI that contains the helper loop.

This checkbox should be unchecked by default.

If checked, a (private) VI is create and contains the helper loop.

The subVI is then dropped inside the Main.vi where the helper loop would have been created.

Once a Broadcast happens, only modules that are registered for it can access the value contained in the Broadcast. If a module starts execution and registers for Broadcasts from another module after that module has sent a Broadcast, the registering module must wait until the Broadcast happens again before it has the latest value. We have encountered some use cases where it is beneficial to know the most recent value of a particular Broadcast. In those cases, we have created workarounds such as a "Refresh" Request that can force a module to repeat all or a subset of its Broadcasts. Of course, that requires the addition of a Request and the code to handle it, etc.

The feature request is to have the Broadcast scripting create two additional VIs for each Broadcast. One VI would be Private, and it would be a data store for the value of the Broadcast event (message). The other VI would be Public, and it would be a Read Accessor for that value. I am picturing the Public VI calling the Private one, and the Private one is a Functional Global. In the Broadcast event VI, the value would get written to the Private VI's Functional Global.

Having a Public VI that contains the most recent value for the Broadcast make it easy to write small state machines or action engines that can access Broadcast value data without Event Structures.

There are other messaging architectures that implement the "Read Global" ability, and it has proven to have value for us in development of some systems.

For Cloneable modules, the "Read Accessor" could take a Module ID as an input.

When dropping the Error Handler and creating the string constant from the input terminal, the DQMH validator will complain about the wrong naming of that constant.

"The Helper Loops do not have a DQMH_HELPER_LOOP_NAME string constant wired to the 'Error Debug' input of the DQMH Error Handler - Helper Loop subVI"

Please change the name of the string input for the Delacor_lib_QMH_Error Handler - Helper Loop.vi from "Error Debug" to "DQMH_HELPER_LOOP_NAME".