Have Broadcast Events for Cloneables take a Module Admin Instead of Module ID

[Taggart]

Here's something I've been running into lately (for whatever reason hadn't done a ton with cloneable until now). I'm sure someone else must be as annoyed by this as I am.

Why do all the cloneable broadcast event VIs take a module ID and not a module admin object? Is there ever a reason where I would want to use a different module ID rather than the current one? I can't think of any, but maybe I am just not that imaginative.

Everywhere I drop a broadcast I have to also drop a property node and pull off the Module ID, why not just incorporate that into the broadcast VI?

By the framework not including that it requires extra effort on my part to wire it all up and it clutters my block diagram with property nodes that don't really add anything.

I'm sure there is probably some reason it was done this way. What use case am I missing where I would want to use a different module ID? and if there is a use case for that, I'm assuming it is an infrequent or minority use case. Is there some way we could make the primary use case the default (ie use the current module ID) without requiring all these extra property nodes, while still maintaining the ability to use a different module ID if needed?

Not sure if there is a way to do this and also make it backwards compatible? Maybe leave the existing broadcast vis as is and mark them as deprecated or something and add a wrapper that takes the module admin and then calls the 'deprecated' VI.

All I know is that there has to be a better way than dropping a property node every time or me manually creating a wrapper for every broadcast.

How does anyone else currently solve this problem?

[Taggart]

In thinking about it, I guess I could just grab the module ID once outside the MHL or EHL and just pass it into the case/event structure, since it shouldn't change. That would eliminate the property nodes. So maybe this is a non-issue. In that case sorry about the rant.

Although I am still curious about the use case where you would want to use a different module ID. What am I missing?

[joerg.hampel]

I usually do exactly what you describe in your second post - place the property node outside the error structure and wire in the Module ID.

[Darren]

Complete guess here (Fab may remember better than me), but I think when DQMH was being designed, the Module ID pre-dated the Module Admin class. So all the VIs in the original version had ID inputs, then when the Module Admin was added later, the VIs just kept the IDs. 

I agree with your assessment that you would never wire in a Module ID to a broadcast VI that is different than the Module ID stored in the Module Admin class.

I also agree that the single property node outside the main VI structures is convenient enough that it's not worth changing the framework over..

[joerg.hampel]

Whenever I demonstrate DQMH, I highlight the fact that the module ID inside the request payload might be the actual module's ID or "-1", and how that affects wiring said request parameter to a broadcast vs. using the module ID in the Module Admin object.

I'm not sure there is a valid use case for this, and I bet that in the huge majority of cases it's the opposite - but maybe there are situations where you actually would like to see the "-1" in the broadcast? 

 

[Darren]

> ...maybe there are situations where you actually would like to see the "-1" in the broadcast? 

I could not think of a reason for this. It's basically a way to anonymize the clone instance that broadcasts the event. Removing information when it comes to framework messaging is never a good idea.

[mbaudot]

Hey Sam, thank you so much for your trust in DQMH and for taking time out of your day to share your idea with us.

You can place a property node for the Module Admin class outside the error structure and wire in the Module ID.

So, we decline this request, at least for the next DQMH version.

Again, thank you for your input; it is most appreciated. Please keep those ideas coming!