Newbie question regarding Module ID in EHL passed to MHL by default in a cloneable.

[Dhakkan]

Hello folks,

I'm test-driving DQMH, and decided to directly play around with version 7 beta due to its helper-loop features.

I encountered a problem where a cloneable module would respond correctly when addressed individually in the API Tester, but would error out when addressed as part of 'All' from the Tester. The root cause seemed to be the Module ID of -1 (i.e. All) being used in the MHL, as wired in by the DQMH framework inside the EHL. This ID was resulting in an event reference NOT being found for a local event to be sent to the Helper Loop. I fixed my problem in the MHL by using the Module ID read-accessor from the 'Mod Admin' class and ignored the parameter included with the MHL message's Data. (Screenshot below)

My question is: I assume the Module ID input field in the EHL's user-defined event is used primarily for gatekeeping, i.e. 'Addressed to This Module.vi'. If so, wouldn't it be better to bundle in the read-accessor of the Module ID in the EHL itself? Alternatively, the Module ID parameter could be dropped from the MHL's Data cluster altogether, and the Module's developer could drop the read-accessor in the MHL as required. Or am I misunderstanding this part of the framework entirely?

[Darren · Accepted solution]

You definitely want to use the Module ID property from the Module Admin class, as you've shown in your bottom image. If I recally correctly, the DQMH 7.0 scripting creates a Module ID property node as a convenience when scripting Local Instance events, but not when scripting private events, as there's no way for the tool to know what your intention is with a private event (send to all, or send to an instance), whereas we always know what your intention is with a local instance event (only ever send to an instance).

[joerg.hampel · Accepted solution]

---

@Dhakkan wrote:

wouldn't it be better to bundle in the read-accessor of the Module ID in the EHL itself? Alternatively, the Module ID parameter could be dropped from the MHL's Data cluster altogether, and the Module's developer could drop the read-accessor in the MHL as required. Or am I misunderstanding this part of the framework entirely?

---

There are cases where you want to implement different behaviour in your MHL depending on whether a request was sent to all clones or only to a specific instance. For those cases, you need to know inside your MHL which module ID a request was sent to. 

I can see how these details are not quite obvious and cause confusion; that's why I put emphasis on this topic when giving DQMH trainings. 

[Dhakkan]

Thank you! Darren and Joerg, for your respective clarifications.

---

@joerg.hampel wrote:

---

There are cases where you want to implement different behaviour in your MHL depending on whether a request was sent to all clones or only to a specific instance. For those cases, you need to know inside your MHL which module ID a request was sent to.

---

If I understand your point correctly, you're stating that MHL business logic could differ solely because of the intended clone recipient, i.e. 'All' or 'Me', for the same input message. I am still assuming that the EHL will enqueue to MHL only if the intended clone recipient is 'All' or 'Me'; so the MHL will not be triggered otherwise for that event.

As an example of what I understand of your scenario, referring back to my opening post's picture, inside the 'Write' case of the MHL there could be another case structure, selecting on the incoming 'Module ID'. Within case -1, i.e. All, there could be some logic. Within case Default, i.e. Me, there could be some other logic. In this latter case, the Developer would use the 'Module ID' property node for instance-specific calls as needed.

This is intriguing! Can you provide an example use case scenario where this is necessary?