DQMH Consortium Toolkits Feature Requests

By default, in the MHL Error case, the "error out" local variable is written to.  But the error that is written is NOT the error that came into the MHL Error case!

I propose the above be changed to this:

By doing this, the actual error that was raised by the module will be copied to "error out"

When you update the DQMH version, you can have hundreds of failures to fix in your projects (not because everything is broken but just because, for example, a new feature requires updating a VI).

A fixer is available most of the time, and you just have to click the button to make the code change.

For me, the UX issue is that after you hit the fix button, you need to select the next failure with your mouse and then click on the fix button. I'm not too fond of this kind of mouse gymnastics.

My proposition: If the fix is successful, the next failure could be selected automatically.

The fixing process would be significantly improved.

When I create a new Broadcast, here's what the new frame in the API Tester looks like:

I almost always end up adding the following code by hand (usually by copying it from another frame):

It seems to me that most of this code could be scripted. Maybe everything except the value of the first format string?

(idea originally posted here)

I would like a right-click plugin where I could right-click a DQMH broadcast subVI and "Find Event Frames". This would search all VIs in my current project for event structures that are registered for the broadcast event fired by the subVI I clicked on, and show me a list of results that I could double-click and be shown the event frames one at a time. Or I guess it could just open all the diagrams for me, since I probably want to walk through all of them anyway.

The operation could take a while, but would be worth it. I often find myself wondering where all the places are in my code that are registered for a particular broadcast.

(idea originally posted here)

As mentioned in DQMH Forum: VI Reentrance issue VIs which are required to be non-reentrant are not reported from the DQMH validation tool if they were changed (e.g. to shared clone)

Some of the important VIs which should be reported:

• Obtain Broadcast Events.vi
• Obtain Request Events.vi
• Clone Registration AE.vi
• Start Module (is already reported)
• Basically all used FGV's

Steps to reproduce:

1. Create Project with a new clonable module
2. Change all non-reentrant VIs to shared clone
   

    

3. Run module validation and execute fix
   1. Start Module.vi will be updated and changed
4. Rerun module validation
   1. No issues reported

Original idea from Matthias Baudot in https://anchor.fm/wired-in-software/episodes/Episode-6---Matthias-Baudot-from-Studio-Bods-emtpti

When you have lots of modules (20+), initializing module selector control tends to take seconds that can be annoying when you need to use the scripting tools.

Finding a way to remove this init time would greatly improve the user experience in large application development.

When creating new module, I'd like a way to add a text explaining its responsibility. It will reinforce good conception practices and allow Antidoc to retrieve information to generate a valuable documentation.

Note: IMO, this content should be added to the module lvlib description.

If this field could optionally mandatory to create the module, I would find this great 🙂

The below image comes from the Error Reported broadcast event case in the API Tester (as found in the default Singleton or Cloneable DQMH module templates):

This produces strings that look like this:

This could be improved by adding the "message" component of the error, by using the Simple Error Handler.vi.  Using the message makes the error report more descriptive, and doesn't rely on the user having to use "Explain Error" to review what the error code's could possibly be related to.

This produces strings that look like this:

Observe that the error message is now present in the text.

Reviewing somebody's DQMH code I noticed an error generated in the exit case where they had cleanup code (1) was not captured by the Tester. This is purely because the exit case causes the MHL to terminate (2), so the normal error handling strategy (3) doesn't work (enqueuing another job called Error). Can I propose, unless there's a better technique, that adding the "Error Report" broadcast at the end of the Exit case (4) is a simple way to ensure any errors generated here get reported.

Add Error Broadcast in MHL Exit Case

Hi, I would suggest adding a boolean called 'Include Dependencies' to the function on the scripting API to search for DQMH modules on the project, sometimes we have projects and we call DQMH Modules not listed on the project itself, but the developer should be aware we are calling those DQMH modules under dependencies, the Panther Dashboard for DQMH already is searching for DQMH modules under dependencies but it would be great if the native function does this functionality, also, I suggest adding a boolean array output to know if the resulting modules are located under dependencies or they are in the project.

This is how I visualize the connector pane of the 'Get DQMH Modules in Project.vi'

Thank you!.

When I need one of the reply payload values of a Request and Wait for Reply VI, I need to unbundle 100% of the time. What if the Request and Wait for Reply VI output the reply payload elements individually on the VI conpane so I don't need to unbundle? I often make this change manually to my Request and Wait for Reply VIs. And I never unbundle the error from the payload, since it's already merged into the error stream inside the VI. So I wouldn't expect that output to be on the conpane. But all the other payload parameters, you betcha!

(idea originally posted here)

When adding a new event, I think it would be really nice if the scripting code that adds the new case structure case to the main VI also scans the event description for formatting tags, and then applies them to the new case's subdiagram label. That way the subdiagram label will be formatted exactly the same way as it appears in the VI documentation. For those of us who adhere to the convention of bold facing control names as we mention them when writing VI documentation.

I feel like a DQMH module isn't "valid" if its Main VI or its Tester are broken. Right now a module with either of these VIs being broken can pass all validation tests. If something goes wrong after I've run some module "fixers" (or perhaps an external factor has caused my module to become broken without my knowledge), the DQMH Validate Module tool seems like a good place to let me know about it.

This is more of a question or request for comments than an actual feature request:

In the dialogue window for creating a new DQMH module, should we rename the caption "Module Type" to "Module Template"? For a vanilla installation of DQMH, there are only two templates to choose from (Singleton and Cloneable), so the caption makes sense. Once you start adding your own templates, not so much anymore. Also, for documentation purposes, it would make things clearer if we separated the term "type" from the term "template".

In addition, it would be nice to see the actual type of the module (singleton or cloneable) added to the name in the dropdown list (see screenshot).

Opinions?

Running the validator on bigger projects takes quite long.

Would it be possible to speed up the process by running the validation of the modules in parallel?

Additionally: Also in CI/CD we know if the module has changed at all. It would be nice if the cli-module-validation could be called with a .lvlib instead of a .lvproj. Therefore, it could be handy to have a VI which lists all dqmh modules in a .lvproj.

Original idea from @FabiolaDelaCueva 

Sometimes you could need to unregister broadcast events. To do this you want to use the Broadcast Events--cluster.ctl, but it's set to private scope (it's totally fine).

Having a public wrapper to this control just giving access to the type and not the current event like you can get with Obtain Broadcast Events For Registration function would be great.

Considering providing a fixer to add this wrapper to all other existing modules.

Prior to DQMH 5, I would sometimes see developers add a VI reference output from Start Module.vi to the cloneable Main VI instance that was running:

This was sometimes convenient for the calling code, like in cases where you needed to insert the cloneable main VI instance into a subpanel or something like that. Unfortunately, you cannot use the same approach with Start Asynchronous Call in DQMH 5.0 and later. The VI Reference output from Start Asynchronous Call cannot be used for similar purposes. So you can't output the VI reference that was used to start the async call and expect your code to work the same. Instead, you'll likely want to create a request to the module that will use the "This VI" constant within the main VI instance itself to perform whatever operation needs to be done on the main VI instance. 

I propose there be a new DQMH Validate Module test that detects cases where the VI Reference output of the Start Asynchronous Call function is wired:

As DQMH module templates become more widely used, it would be very nice if, when adding a new DQMH module that was added as a custom template, the overlay pre-populated with the overlay that the template uses.

So maybe thinking about this on a lower level, this feature request comes in two parts. When saving a DQMH module as a template, store the metadata that makes up the current overlay in a config file somewhere. Then, on the Add New DQMH Module window, whenever a custom Module Type is selected, pre-populate the overlay with that metadata.

When opening a DQMH module .lvlib file directly, the LabVIEW IDE allows to call the DQMH Scripting Tools from the Tools menu, which results in an error message when trying to parse the project for modules:

This error should be handled the same way as when calling the DQMH Scripting Tools from a single VI (or even the getting started window):