DQMH Consortium Toolkits Feature Requests

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

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.

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.

Any reason not to?

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 🤔

Using DQMH 7.0.1.1316 (currently the latest version), the error message generated inside the Default case of the Message Handling Loop is "The invalid message string "%s" was received in the Message Handling Loop for module "%s"."

"The invalid message string "%s" was received in the Message Handling Loop of module "%s"." might be a small improvement.

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.

I saw that this request for automatically refreshing the modules was released: https://forums.ni.com/t5/DQMH-Consortium-Toolkits-Feature/Auto-press-the-refresh-button-on-cloneable....  I am thrilled that idea was submitted, approved, implemented, and released by the time I got here to submit the idea.

I believe there is one other aspect of the API Testers that should be configured by default: the visibility of the Show Block Diagram and Show Diagram on Init buttons.  Since these buttons have no use in an executable, they cause confusion for operators.  I would propose the following code is scripted (instead of me needing to add it to every API Tester):

Thanks,

Scott

When preparing a project for Lumos tracking...

Lumos adds "Trace VIs", when migrating this code to another PC without Lumos installed
When opening DQMH module it asks for all the "Trace VIs" and breaks the code...

It be great to have another option to Remove or Un-prepare project for Lumos Tracking and be able

to distribute this code without Lumos installed

Thanks! Great tool!

In DQMH 7.0 you can create private requests now. This is a feature that I really like and the more you use something, the more ideas come to you.

In my current project I created a private request and shortly after I realized, that I need to call this request from another module. I tried to convert the private request into a public request, but this wasn't easy.

So here comes my idea: why is the conversation (public requests → private requests and privat requests → public requests) not included in the Convert DQMH Events dialogue? That would be the place where I would intuitively look for it.