DQMH Consortium Toolkits Feature Requests

Similar to this request.

I would like a button, on the API tester VI that ships with DQMH, to clear the status display.

Hi, I'm currently refactoring some old code that contains helper loops, those helper loops weren't created using the DQMH Scripting tool, to homologize them, I'm following the helper loop prerequisites described here , one of the prerrequisites is that the error debug input to have a constant with the label "DQMH_HELPER_LOOP" and write the actual name of the helper loop, what I'm proposing here is to change the Error Debug name to this label only for the Error handler - helper loop.vi

This will help us create a constant for this input with the label already there, eliminating the need to visit the DQMH documentation website to get the right name.

Best Regards,

Enrique.

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

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.

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? 

There doesn't appear to be a distinction between standard Requests and Wait for Reply type requests for LOCAL INSTANCE.

I think this why when using the Remove DQMH Event Tool on a LOCAL INSTANCE Request and Wait for Reply, the "Request (Reply Payload)--cluster.ctl" file is not removed from the library and deleted as it is for public Requests.

Not a big deal, but would be a nice addition to not have to remember to remove it manually.

Thanks,

Aaron

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.