DQMH Consortium Toolkits Documents
EDIT: We now have a place for you to post DQMH Feature requests here:
https://forums.ni.com/t5/DQMH-Feature-Requests/idb-p/delacor-ideas?profile.language=en
Hello everyone,
We have been getting DQMH feature requests via this forum, via conversations during NI events and direct e-mail. We keep track of every suggestion in our internal tracking system, but we thought it would be a good idea to have a central location for others to add their own requests. Please create a different discussion for people to discuss your feature request and point to that entry in your post here.
We will add some of the ones we have already received. If you find a feature request you agree we should implement, please vote by clicking on the "Kudos" button for that post. Also, our CCFO (Cheap Chief Financial Officer) has asked us to add the following: "If you consider a feature to be particularly important, be sure to mail in your vote written on the back of a new US$100 bill. Multiple votes are, of course, allowed and encouraged"
The more votes we receive for a particularly important feature, the more likely we are to implement it!
Best regards,
The Delacor team
Current feature requests:
Add a Rename Event utility to the Tools>>Delacor>>DQMH menu
Status: Done. Implemented in DQMH 3.0
Add a code to cloneable modules to make them behave as singletons
Status: Done. Implemented in DQMH 3.0
Add by default an error cluster in the Reply argument for Request & Wait for Reply Request Events
Status: Done. Implemented in DQMH 3.0
Add Request events to TestStand insertion palette if TestStand is installed
Status: Won't implement.
Support DQMH Modules Templates when creating a new DQMH Module
Status: Done. Implemented in DQMH 3.0
in DQMH 4.0 added the option for these templates for them not have to be installed in the LabVIEW Data folder, instead, the metadata file can include a full path instead of a relative path.
Discussion: DQMH first experience and a bit of a feature request
Add support for Real-Time or create a new DQMH module/project that would work on Real Time Targets
Status: Done. Implemented in DQMH 4.0
Discussion: Any caveats in using DQMH on Real Time
Module initialization with input from creator via Start Module
Remove the need for an argument when creating a new event
Status: Won't implement Implemented option to not have to add arguments in DQMH 3.0
Discussion: No arguments discussion
A way for the creator of a module to provide parameters for the Message Handler Initialize case
Status: Done. DQMH 2.1, we added a "code needed" bookmark with instructions inside Start Module.vi, so the developers would know where these initialization arguments if they needed to.
Discussion: Module initialization from Start Module and other ideas
A way to name modules/module clones during creation and then address them by name instead of by Module ID
Status: Wish List
Discussion: Module initialization from Start Module and other ideas
Requests with a To/From/Reply To header
Status: Wish List
Discussion: Module initialization from Start Module and other ideas
Floating Dialog Box for the Delacor Tools
Status: Wish List
Discussion: No discussion, the suggestion by K.Ross found further down in the comments to this document. If you want to discuss it further, feel free to start a new discussion.
Folder Cleanup
Status: Wish List
Discussion: No discussion, the suggestion by mRadziwon found further down in the comments in this document. If you want to discuss it further, feel free to start a new discussion.
Separate VI residing in each of DQMH_MESSAGE_CASES.
Status: Won't Implement
Discussion: No discussion, the suggestion by mRadziwon found further down in the comments in this document. If you want to discuss it further, feel free to start a new discussion.
Move sequence structure in Request and wait for reply to have access to merge errors
Status: Won't implement. The majority of DQMH developers remove the sequence structure anyway. It is there to facilitate scripting.
Discussion: No discussion, the suggestion by mRadziwon found further down in the comments in this document. If you want to discuss it further, feel free to start a new discussion.
Add the ability to choose the Icon Editor, currently only the default works. (I use Mark Balla's Icon editor.)
Status: Won't implement.
Discussion: No discussion, the suggestion by jdebuhr found further down in the comments in this document. If you want to discuss it further, feel free to start a new discussion.
Scripting API
Status: Wish List
Discussion: Scripting API
Combining the functionality of all 3 event types of DQMH
Status: Wish List
Discussion: suggestion by Barney10 found further down in the comments in this document. Also discussion available via Combining the functionality of all 3 event types of DQMH
Floating Dialog Box for Delacor Tools
It would be great to have a floating window that provided faster access to the Delacor Tools. I find it a bit clunky having to navigate through the menu every time I want to create an event. Especially in the scenarios where I have designed my module and I just want to build it up fast.
My suggestion is to have a floating window going from this (below)
to this (below)
But having it available from the menu and/or the floating window.
Sorry if this is already a feature and I have just missed it.
Thanks
Kev
Add the ability to choose the Icon Editor, currently only the default works. I use Mark Balla's Icon editor.
It would be great if there was a polymorphic VI which held all the public APIs and got modified after creating new public APIs.
This would speed up the process of accessing the APIs using quick-drop. So the polymorphic VI could be dropped and the right instance chosen easily.
DQMH Version Constant VI
In order to display or log the DQMH version number which any given application is built on, I pull it from a random DQMH VI by parsing its documentation tag:
_____ Based on Delacor QMH Project Template 4.0.0.41.
So far so good. But depending on what exactly I want to achieve with this, I cannot just randomly pull this information from any given DQMH VI. I can read the Delacor QMH Project Template version that the VI was created with, and I can read the Delacor QMH Palette version. I cannot read the version of Delacor QMH as it shows up in VI Package Manager (if I'm not mistaken).
Feature Request: A VI that gets installed with DQMH that returns the version number of the currently installed .vip. I guess it's quite easy to script one...
Strip HTML formatting from VI description for MHL subdiagram label
All said, I think.
Feature Request: Remove the <b> and </b> tags from the description text before writing it to the message case's subdiagram label.
Icon Overlay for Broadcast VIs
Sometimes when looking at a DQMH (main) VI's block diagram, I find it difficult to spot which VIs are just subVIs encapsulating functions, and which VIs are broadcasting and communicating data to the outside world. Our coding conventions now make a rule of manually changing the VI icon of broadcast VIs to carry a glyph symbolizing the broadcast character, as can be seen in the screenshot below:
(We dictate icon layouts and colors. The colored bar is green because this is a User Interface module. The colored square is used to distinguish multiple UI-related modules from each other. The broadcast glyph is then colored as the square is, but with inverted colors.)
Here's the glyph PNG that we put into LabVIEW's data folder, eg. C:\Users\admin\Documents\LabVIEW Data\Glyphs\
Feature Request: Change the VI icon of broadcast VIs during generation (automated scripting) so they are more easily distinguishable.
Edit: More details in my guest blog post on delacor.com/vi-scripting-add-glyph-to-vi-icon/.
Feature Request: Rename DQMH Event - Ability to edit description
When renaming an event, include a control to display the description of the event so that it can be edited and updated automatically.
Feature Request: Create New DQMH Event - Two Argument Windows for Req&Wait4Reply
Feature Request: New menu option: Save DQMH Module as Template
New menu item: Save DQMH Module as Template. This would allow the user to select a module and save it as a template. A dialog would appear prompting the user to select the DQMH module they would like to save as a template. This would then automatically create the xml file, and copy the module over to the LabVIEW Data folder, ready to be used as a template. Saves a lot of time and confusion with regard to setting up the xml file.
Error tolerant "Module Did Init" Broadcast Vi
if i put some initialization code into the "Initialize" MHL-Case and there occurs an error, the Module Did Init Broadcast will not be send if the error wire is wired through.
That's why i have to modify the code to route the error around the broadcast-vi:
I like to have the error routing code integrated into the "Module Did Init" broadcast vi:
This would guaranty the message will be send always and makes the code in MHL case cleaner.
regards,
Thomas
API Tester and request VIs for cloneable modules
When creating new requests, DQMH 4.2 now not only creates the case in the API Tester but also creates a button and links it to that event case. For singleton modules, all done and dusted. For cloneables though, I still need to wire the module ID.
Feature request: When scripting a new request into the API Tester, connect the module ID wire coming from the shift register to the "Module ID" terminal of the new request VI.
Feature Request: Option to create a cloneable version of a singleton module
Bonus Feature: Option to create a singleton version of a cloneable module.
The benefit of such a feature would come from the fact that we have a number of internal team templates, and we often need to maintain update two of each ( a singleton version, and a cloneable version). The main reason we need to do this is because RT requires all modules to be cloneable, but Windows does not. So when we build up our internal team templates, we need to create two - a singleton for Windows and a cloneable for RT. But if we had such a feature we could simple code up a singleton, and then convert it (or save as) to a cloneable.
Feature Request: Script the 'Status' string update code in the API Tester for new broadcast events
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?
Feature request: Plugin framework / Automated packaging into ppl upon build
The current way to use DQMH with plugins (packing it into a ppl) is, unlike so many of the other nice features of DQMH, not a smooth automated process - and doing it means you lose access to many of the scripted features of DQMH.
It would be great if plugin architectures were handled by the toolkit itself - meaning we could use DQMH as it is all the way until we need to build the application, and then the DQMH toolkit would automatically take care of the steps required to convert the solution into one based on ppls 
Message Name in Error Handler for Message Handling Loop
Sometimes, the error cluster that feeds into the Delacor QMH Error Handler - Message Handling Loop.vi doesn't convey enough information to identify the origin of the error. For example, an Error "91 - Variant To Data in xyz.lvlib:Main.vi" does not tell me in which MHL case the variant to data operation failed. It would be nice to have the selector label of the MHL's case that the error occurred in.
Feature Request: Somehow (not sure what the best way would be) make the error handler include the last message's name (string) in the error broadcast.
