DQMH Consortium Toolkits Feature Requests

Handle Exit.vi executes Hide VI Panel.vi.

If the module's front panel is inserted into another front panel via a subpanel, the main panel will be hidden, which could cause the entire application to disappear.

The solution is to use the Remove VI method before the Stop Module API method.

An example illustrating the use of subpanels with DQMH would be interesting.

It would be nice to have an example provided with the framework to demonstrate the implementation of a plugins architecture with DQMH :

Main Application (sources) <---> Plugin Interface (PPL) <---> Plugin (sources or PPL)

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.

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.

When refactoring "Request" events into "Request and wait for Reply" events the scripting tools always create a new MHL case. If just wanted to modify the existing event I need to copy reply code, delete the new MHL case and add the reply code to the old MHL case.. 

It would be much better if the new MHL frame would be a checkbox option and the normal behavior is that the reply code just gets added to the original MHL case 

In the helper loop this already works and the reply gets directly wired.

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.

My use case is simple :

I have a module that uses DAQmx functions, so the module's main VI will only be executable in DAQmx is installed.

Having a public VI from the module to check if the main.vi is executable is, I think, the fastest way for my app to report that a feature is not available due to missing driver.

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.

Please create and add checksums for the Core and each of the individual packages.  This is necessary for companies to be able to trust the integrity of software being downloaded.

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.

Add an always available "None" option in the drop list, 

Selecting this option will avoid creating a case for the event in the Message Handling Loop (MHL) nor any other place

Here...

so by default this droplist will include, 
- Event Handling Loop
- None (this will avoid generating a consuming case anywhere)

or it could be 

a checkbox next to the consuming event loop droplist

to allow developer to select avoid generating it

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