No arguments - discussion

[Thoric]

I'm exploring DQMH and suitably impressed by the level of effort that's gone into it.

I'm replicating an application in several frameworks and am in the throws of developing my first DQMH module, called ConfigData. This module is a service (call it an actor if you like) that loads and saves configuration information from file. It also requests and receives certain configuration information from n other actors, and the same n actors can call upon it for specific information too.

In my design ConfigData has an API which includes the ability to makes Requests of it, including "Load Configuration from File", "Save Configuration to File" etc. These requests are sent by the owning parent actor. Being "Requests" (and not Set or Get messages), they hold no parameters, and this is where I immediately stumbled in DQMH. Using the Create New DQMH Event wizard I was required to add at least one argument to my new UE.

Now, I don't need any arguments in my requests to "Load Configuration" or "Save Configuration", and I was intending to create one new UE per request. This fits well with my brain and how I like to organise my messaging structure. But if you can't have zero-argument messages (UEs) in DQMH are you perhaps required to group them up, create one single UE and include the type of message inside as an argument? For example, create a new UE called "ConfigData Requests" and have an enum in the argument with the options 1. Load Configuration, 2. Save Configuration etc.? If so, what do I do with a possible third message "Get Recent Projects List" which does have associated arguments? Do I add a second argument to my UE, perhaps a Variant, to accommodate these extras? Or create a wholly new UE and keep it separate from the grouped Requests UE?

Thanks in advance for the advice.

[Darren]

I always drop a dummy boolean in the Arguments Window, then I just remove it from the conpane of the Public Request VI, and wire a dummy constant on the diagram of the request VI. Then, users of the module (who only ever interact with the public API) never see it...for their purposes, it is a request with no arguments.

[FabiolaDelaCueva]

Darren wrote:

I always drop a dummy boolean in the Arguments Window, then I just remove it from the conpane of the Public Request VI, and wire a dummy constant on the diagram of the request VI. Then, users of the module (who only ever interact with the public API) never see it...for their purposes, it is a request with no arguments.

That is what I do as well. I created the following video explaining the reasoning behind enforcing the creation of arguments. We wanted to ensure that the placeholder was there in case the developer changes their mind in the future and decides that, after all, there needed to be an argument for that event.

Regards,

Fab

[Thoric]

Thanks Darren and Fab,

I can see your point above, the approach is extensible and has value but it does sometimes feel like a workaround to an implementation limitation (the underlying User Events need a datatype).

Couple this with my realisation that for modules with many dozens of messages, and with a view to achieving better decoupling between modules, I'm beginning to wonder the virtues of class based messaging within the DQMH. Something I need to ponder on a bit, but have you any previous experience on this approach within DQMH?

[FabiolaDelaCueva]

Thoric wrote:

Couple this with my realisation that for modules with many dozens of messages, and with a view to achieving better decoupling between modules, I'm beginning to wonder the virtues of class based messaging within the DQMH. Something I need to ponder on a bit, but have you any previous experience on this approach within DQMH?

The arguments window can take any control, so you could paste an object or even the LabVIEW object and it should work. We have used classes in the arguments for our events. We tend to limit the use of classes to be either in a couple of events or the local data of the Main.vi message handling loop. We believe that leaving the block diagram of the DQMH Main.vi looking closer to the NI QMH makes it more accessible to different levels of LabVIEW proficiency.

If you decide that you will use a message class as your argument and that you will have a single Request, a single Broadcast and a single Request and wait for reply, at that point you would be relying on casting to a different class on the message receiving end and on dynamic dispatch. Sounds like at that point the command pattern would be implemented and the two loops pattern on the Main.VI would be transformed into something closer to Actor core. So you would be creating something like Actor Framework, except the inter process communication mechanism would be events instead of queues.   You probably won't benefit of the scripting tools that much at that point.

We would be interested on learning more about your findings.

Regards,

Fab

[Thoric]

I've had the same thoughts, plus wrapping the module definition in an overridable class structure to promote module hierarchy and reuse. I think this could get me where I want to be. I'll keep you informed 🙂

[FabiolaDelaCueva]

Hi Thoric,

I wanted to let you know that there are two new features in DQMH 3.0 that will address some of your concerns above.

1. Now you will be able to tell the event scripter to not remind you that you need to add an argument. If you don't add an argument, it will create a dummy argument for you in case you change your mind later (as stated above).
2. You will be able to create new DQMH modules from your own DQMH templates.

If you are interested in becoming a Beta tester, please sign up to our DQMH newsletter (if you have not signed up already). We will be sending the link to the Beta testing site in the next couple of days.

Regards,

Fab

[Thoric]

Thank you for the update Fabiola.