DQMH Consortium Toolkits Feature Requests

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?  ... View more

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 ). ... View more

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

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

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

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

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

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

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

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

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

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:   Open the public event VI Create a new control or indicator OR remove existing Expand the bundle/unbundle, and wire it in OR collapse the bundle/unbundle to get rid of the deleted argument(s) Wire the new item to the conpane and set it to Required (in the case of a control) Update the EHL case to make sure the cluster is properly bundled (can be checked by the validator) 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. ... View more

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

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

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

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). ... View more

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).     ... View more

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

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