12-20-2023 01:50 AM
Hi,
I have DQMH module which has a Send Message request. The purpose of this request is that the requesting VI can send simple string messages to the GUI of the DQMH module. Other than this the module does nothing with the message, it simply broadcasts it so the GUI can capture the broadcast and display it on its front panel.
This is where I'm somewhat concerned if I'm doing the right thing, because I can implement this only with a Roundtrip request, which looks like an overkill:
I'm not sure if this is a problem for others, but I've been in this many times that what I really need is a VI I can call outside of my module a directly broadcasts data.
Its possible that I do something what is conceptually wrong, so I'm wondering how others would solve a problem like this. Its also possible that this is the way. Another possiblity that there could be a 5th type of a request which is either a "Request+Broadcast" without a returning payload or a public broadcast.
Thanks.
12-20-2023 03:00 AM - edited 12-20-2023 03:04 AM
@1984 wrote:
I've been in this many times that what I really need is a VI I can call outside of my module a directly broadcasts data.
I'm not sure I understand why you need this functionality many times. I'm not saying that it's wrong, but it's surely not a standard use case, so maybe it's worth some additional consideration?
I can remember a single application where I needed to trigger a broadcast from outside the module (*), and I simply created a wrapper VI for the broadcast with public access scope 🤷
(*) Edit: And thinking about it some more, this was only to simulate a certain situation from the API tester.
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® (Developer Experience that makes you smile )
12-20-2023 03:30 AM
I'm not sure I understand why you need this functionality many times. I'm not saying that it's wrong, but it's surely not a standard use case, so maybe it's worth some additional consideration?
Example: that you have two dqmh modules running in parallel. Both has a GUI (not the module main and not the API tester but separate GUI displayed to the user) and the GUIs need to exchange data. Is this a better example? Basically what I'm creating is a way for the GUIs to communicate with each other. As written above I can imagine that I'm doing something which I should not do (or do it differently), but this actually happend to me multiple times in the past ~12 months since I'm working with DQMH.
I can remember a single application where I needed to trigger a broadcast from outside the module (*), and I simply created a wrapper VI for the broadcast with public access scope 🤷
So just created a VI in the Public API which included the broadcast? That could work 🙂 Maybe a new virtual folder called Public broadcasts in my projects.
12-20-2023 04:59 PM
Two different ways to approach this.
1. Create a Message Broker module that sits hierarchically at the top of the tree, where GUI 1 and GUI 2 are both dependencies.
If something occurred on GUI 1 (ie user pressed a button), broadcast this to the new message broker module. The message broker module would then receive this event, and then call a request of GUI 2 to inform it of the update. And Vice versa.
2. Or you have a hierarchy between the two GUI modules.
ie GUI 1 is top, and GUI 2 is bottom, therefore GUI 2 is a dependency of GUI 1.
If something happened on GUI 2, simply broadcast this to GUI 1. If something happened on GUI 1, call a GUI 2 request to inform it of the change.
12-21-2023 01:49 AM
1. Create a Message Broker module that sits hierarchically at the top of the tree, where GUI 1 and GUI 2 are both dependencies.
If something occurred on GUI 1 (ie user pressed a button), broadcast this to the new message broker module. The message broker module would then receive this event, and then call a request of GUI 2 to inform it of the update. And Vice versa.
Not sure if I got this right, but for me it seems that the first solution complicates the situation even more by introducing a third module. GUI1 can call the request of the broker module, but as GUI2 has no requests (as GUI1 and GUI2 are not DQMH modules), the broker module can only broadcast a message which has to be captured by GUI2. This doesnt seem to simplify anything as with less effort GUI1 can call the request of DQMH2 which broadcasts a message captured by GUI2. Plus the comments below for the second solution applicable for this one as well.
(If there is an extensive communication between modules/GUIs then sure a central broker could help a lot thats true, but for this exact situation that would be an overkill)
For the second:
ie GUI 1 is top, and GUI 2 is bottom, therefore GUI 2 is a dependency of GUI 1.
If something happened on GUI 2, simply broadcast this to GUI 1. If something happened on GUI 1, call a GUI 2 request to inform it of the change.
I think that was the core of my question. I dont see how GUI2 can "simply broadcast" anything to GUI1 (or in fact to anybody). Broadcasts are private for the module so GUI2 can't call a broadcast of GUI2 directly. This is why I came up with that "brilliant" solution you see in the first comment. A request which simply broadcasts the argument(s) can be captured by a GUI.