Is Broadcast Events--cluster must stay private ?

[Eric_BOB]

In my VI where I use broadcast registration, I would like to modify the registration name of the user event. 
But I can't because Broadcast events -- cluster.ctl  is private and that breaks my VI.
Do you know other methode to avoid this ? Is there risk to modify access from private to public ? 
Just a slamp of code to see the problem.

[ChrisFarmerWIS]

Can you try using Rename DQMH Event?

[Eric_BOB]

Hi Christopher

No, renaming  DQMH Event have no effect for that. The name of the "Ref" to event registration  come from LabVIEW and not from DQMH.

My desire to change this name comes from the fact that in French it is particulary long, as you can see in the example.

Normally, this kind of trick to rename "Ref" to event registration works well, but not in this case where the type of datas associate with this "Ref" are private. The only solution I have found to solve the break arrow, is to modify the property of "Broadcast Events--cluster.ctl" from private to public. But I'm uncertain if this change is a good practice.

[joerg.hampel · Accepted solution]

Hi Eric, the scope of the containing cluster for the broadcast references has been discussed repeatedly in the past, and so far the majority vote has always been to leave it private. With that being said, if a feature request was to pop up, the consortium would be forced to revisit this topic...

The two "correct" (from a point of view of DQMH) solutions to your use case that I'm aware of currently are to

1. unbundle the references and rebundle them into your own, separate cluster. 

2. create the registration with a duplicate of the private cluster and then update with the actual broadcast references:

 

Both options need manual syncing between the private cluster and your duplicate whenever you add or change broadcasts. Sorry I'm not being more helpful 🤷‍♂️

[Eric_BOB]

Thanks Joerg for your workaround.

Just to be sure, need I put Duplicate in public ? or  Outside  Module library ?

Eric

[joerg.hampel · Accepted solution]

Both are fine in my opinion and depend on how/where you maintain other code.

Are you only using it in a single calling place? Then you could even maintain it there, it is part of the scaffolding for processing those events. You could even decide that you only need a handful of events and do the rebundling like that. We have surely done that in the past.

Do you want your module to "offer" that option many other callers? Then I'd maintain it inside the module library in the Public API folder.