DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Is Broadcast Events--cluster must stay private ?

Solved!
Go to solution
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.
Eric_BOB_0-1697122028466.png

 

0 Kudos
Message 1 of 6
(774 Views)

Can you try using Rename DQMH Event?

Christopher Farmer

Certified LabVIEW Architect and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

0 Kudos
Message 2 of 6
(745 Views)

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.

 

Eric_BOB_0-1697185030037.png

 

0 Kudos
Message 3 of 6
(740 Views)
Solution
Accepted by topic author Eric_BOB

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:

events.png

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 🤷‍♂️




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


Message 4 of 6
(731 Views)

Thanks Joerg for your workaround.

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

Eric

0 Kudos
Message 5 of 6
(727 Views)
Solution
Accepted by topic author Eric_BOB

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.




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


0 Kudos
Message 6 of 6
(723 Views)