DQMH first experience and a bit of a feature request

[PNHorn]

Hey Fab and Chris,

Hope you're having fun at NI Week. I've been using DQMH again yesterday and today to build a customised Teststand UI. I got all the Teststand method and property nodes sorted out to do what I needed by yesterday afternoon and then wanted to move it over to DQMH to make it more flexible and scalable. First, just let me say its awesome! I've gone from a single VI front panel which had a fixed number of threads, to a scalable version which can launch new threads as needed in a few hours work. Very happy with that!

I'm not sure if it is possible for you to add this at some point (or if other users would value it) but it would be cool if I could define some additional base messages for a DQMH module to respond to, and then build further DQMH modules with that new functionality built in. The specific example I'm thinking of is that I'm creating a bunch of DQMH's of different types which can be loaded into a sub-panel on a parent DQMH front panel, or undocked to be used in isolation. Rather than put the management of the inserting and removal of modules to the parent sub-panel, I'd like to send the module a message together with the sub-panel reference and tell it to insert itself in the sub-panel. There's a couple of reasons I'd like to do it that way:

• Some of the plugin modules I'll be creating are from cloneable DQMH modules. A messaging framework for communicating with those modules is already provided with DQMH so I want to reuse that rather than tracking and managing which modules are open from the parent.
• I want the module to evaluate whether it is in a compatible state for docking into the sub-panel before it gets inserted - so if the module has already been undocked and is being viewed separately, it cannot be inserted into the sub-panel for example.

I hope that makes sense. It's nothing I can't get around but if the feature was there it would save even more time (unless I missed something and it actually is possible within the framework at the moment).

Cheers,

Pete

[CRoebuck]

Peter_Horn_NIUK wrote:

Hey Fab and Chris,

Hope you're having fun at NI Week.

Hi Pete,

     Great to hear from you. We are both very excited and nervous about NI Week. It’s a busy week for sure and making sure we meet all the people we want to meet with can be a challenge.

I've been using DQMH again yesterday and today to build a customised Teststand UI. I got all the Teststand method and property nodes sorted out to do what I needed by yesterday afternoon and then wanted to move it over to DQMH to make it more flexible and scalable. First, just let me say its awesome! I've gone from a single VI front panel which had a fixed number of threads, to a scalable version which can launch new threads as needed in a few hours work. Very happy with that!

     Wow, thanks for taking the time to dive into this and providing encouraging feedback. We’re very proud of the DQMH  and hope people can find a use for it in their “bag of useful tools”. Your TestStand use case is particularly interesting. Is this something we will be seeing in a public forum anytime soon ?

I'm not sure if it is possible for you to add this at some point (or if other users would value it) but it would be cool if I could define some additional base messages for a DQMH module to respond to, and then build further DQMH modules with that new functionality built in.

     This sounds like a very interesting idea. One thing we have considered is to allow an event to be created in multiple  modules at the same time. So for example you could add the Do Something to all DQMH modules in the active project.   We can’t make any promises to add this but certainly if people give us the feedback and make these requests for sure we will consider adding it to the toolkit. Would this feature help you?

Another option would be to have DQMH Module templates that we could create modules from. Just like the Project Template does when it copies the DQMH Singleton and Clonable templates. Is this more what you are referring to?  Again, no promises to add this.

The specific example I'm thinking of is that I'm creating a bunch of DQMH's of different types which can be loaded into a sub-panel on a parent DQMH front panel, or undocked to be used in isolation. Rather than put the management of the inserting and removal of modules to the parent sub-panel, I'd like to send the module a message together with the sub-panel reference and tell it to insert itself in the sub-panel. There's a couple of reasons I'd like to do it that way:

• Some of the plugin modules I'll be creating are from cloneable DQMH modules. A messaging framework for communicating with those modules is already provided with DQMH so I want to reuse that rather than tracking and managing which modules are open from the parent.
• I want the module to evaluate whether it is in a compatible state for docking into the sub-panel before it gets inserted - so if the module has already been undocked and is being viewed separately, it cannot be inserted into the sub-panel for example.

     There are basically two options to implementing inserting into a subpanel. Either a request to the Module to return its VI reference and then the module is exposed to bad things happening to it. Another option is to create a request to the module to insert itself into the subpanel if the module is in a state compatible with inserting itself into the panel. The subpanel owner then would have to make sure that the subpanel is empty before it makes the request. This option does  not expose the reference and as you mentioned, you can take advantage of the clone instances management already in the DQMH module.

     Chris & Fab

[PNHorn]

Hi Chris & Fab,

Sounds great. Adding the same event to multiple modules at the same time would be great. That would mean that I could develop the modules as stand alone UI's to start with, and then add the events to integrate them into a plugin UI with a couple of standard events for each module. The only disadvantage of doing it this way round would be that any code required to action the event (such as the sub-panel method nodes in this example) would not be copied over to each case automatically, and would have to be manually added. The DQMH module templates sounds like it could work nicely, I'd like to see how that might work.

The Teststand code I've done so far will probably end up in my CLA Summit session planned for next year, but the point of the session is something else - I just needed a bunch of modules to do something, and a customer was asking how to do something similar so I thought I'd combine a few problems into one. I could definitely post just the DQMH code up here or something if that would be helpful. I want to neaten up the code a bit but I'll try and get it posted soon.

Cheers,

Pete

[FabiolaDelaCueva]

Peter_Horn_NIUK wrote:

The DQMH module templates sounds like it could work nicely, I'd like to see how that might work.

As we get more ideas about this, we will post it in this group. Stay tuned.

Peter_Horn_NIUK wrote:

The Teststand code I've done so far will probably end up in my CLA Summit session planned for next year, but the point of the session is something else - I just needed a bunch of modules to do something, and a customer was asking how to do something similar so I thought I'd combine a few problems into one. I could definitely post just the DQMH code up here or something if that would be helpful. I want to neaten up the code a bit but I'll try and get it posted soon.

This would be helpful, so, please do share if you don't mind.

Thanks,

Fab

[FabiolaDelaCueva]

FabiolaDelaCueva wrote:

Peter_Horn_NIUK wrote:

The DQMH module templates sounds like it could work nicely, I'd like to see how that might work.

As we get more ideas about this, we will post it in this group. Stay tuned.

Hi Peter,

DQMH 3.0 includes the creation of new DQMH modules from your custom templates. If you would like to test this out as a Beta tester, please sign up to our DQMH newsletter (if you have not done so already ).

We will be sending the link to the DQMH Beta testing page in the next couple of days.

Thanks,

Fab

[FabiolaDelaCueva]

Updating this thread to include that:

Creating DQMH Modules from Templates was implemented in DQMH 3.0.

And 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.