Sharing/reusing messages between DQMH plugins

[FabiolaDelaCueva]

---

@McQuillan wrote:

Hey Fab,

*The project template idea was from a recording of your NIWeek presentation last year. You mentioned module templates, then said if you have multiple modules working together we could make a project template - That was the light-bulb moment!

---

You made my day! 

Sometimes I wonder if it makes sense to invest all that time in preparing for presentations. Knowing that it helped at least one person, makes it all worth it.

---

@McQuillan wrote:

So now when I want a new plugin, I can create a new project from a template, change the user interfaces, change the "business logic", append some local messaging, and build it. It will then integrate with the root UI and all its subpanels with no extra work. 😄

 - Best of all, each of those ~7 actors can be run individually (tree hierarchy), and they all have testers... #bliss

Next time someone tells me that nobody uses Project Templates with LabVIEW, I will be able to say... well Tom and Delacor do 🙂

Happy wiring!

Fab

[drjdpowell]

Another thing to note is that stuff that in the AF is often done by inheritance can usually also be done by composition, with multiple modules containing a common component that handles a subset of messages.  The Registration messages in Messenger Library are handled by a common component rather than inheritance (in fact, the registration messages are Command Pattern Classes, interestingly, though that isn't required).

[McQuillan]

It's been a while, however, I thought I should close the loop so this thread so it can help other developers.

Taking inspiration from Joerg/HSE's DQMH Application Template, I saw that common nested modules would have their 'default messages' (both broadcast and request) defined. Provided the data types of the events were the same, they could share event cases. HSE's approach was to load the modules from file using VI Server.

I took an OOP approach to achieve the same thing. However, I chose OOP so I could draw a lot of inspiration (copying) from the Actor Framework (which is my standard framework to use). I encapsulated the Public API  (on three inheritance levels 'Plugin'>'Cloneable'>' Specific Module') this was so I could add messages for the specific plugins without changing the 'defaults'. It also meant I could add custom data to the module, and treat the object as an "AF Enqueuer". I also have a register that's mostly copied from AF.

Regarding workflow, I'm using a mixture of module and project templates, so I don't have to re-do any of the leg-work.

Please see below for some screenshots - I would welcome feedback. (apologies for the broken wires - that's a snipping tool "feature", I guess this happens because the snipping tool assumes public scope).

Adding to Register

Adding to register 

Launching Nested Module

 Launching a nested module

Removing from Register

 Removing from register

Stopping all Nested Modules

 Stopping all nested modules

[FabiolaDelaCueva]

This looks interesting and shows that one can indeed add as much OO as they want to DQMH.

Do you have an example of this in a public repository? I would like to give it a try.

Thanks,

Fab

[McQuillan]

Hey Fab,

I'm still working on the framework and I want to add a bit more scripting, but once that's done I'll send you a link 🙂

(Same for you Joerg 😀 )