Dqmh module registered to its own broadcasts

[Taggart]

I can certainly see that for things that don't need to update the state data.  That makes sense.

But in this case, they just had an event for the button press which generated an event which then enqueued something.  So basically they just hit the EHL twice to enqueue data the MHL, instead of just queueing it up the first time....

Honestly this is all in their "Main" module, which just calls all the other modules... It really doesn't even need to be a DQMH module.  Maybe that is the ultimate solution...

[joerg.hampel]

Sam,

I'm not sure about the main VI being a DQMH module or not, to be honest.

For Windows applications, our main VI is really only a "startup" VI that loads modules dynamically. We have one dedicated User Interface module with a subpanel, menu bar, status bar etc. Both startup VI and User Interface module are generic and reused (copied) in different projects. I think that works nicely.

For the first Real-Time applications with DQMH (on Linux RT with embedded UI), we do have a main VI with quite some functionality like displaying broadcasted status and error information. There's also some state machine logic, so we have another non-DQMH event for that "proprietary" communication. In our latest RT project (not Linux but ETS, no embedded UI), the main VI really only starts the DQMH modules and then sits there and does "nothing".

What I'm thinking here is that if you have a main VI with logic in it and it is not a DQMH module, you might end up implementing a QMH or something similar manually...

[Rafal_Kor]

Fab, you wrote in your reply about the use of private requests. May I ask why risk it? Why even create a request, be it private, just for someone to misuse it? What I've been doing is to declare an event, that is local to the module and whose refnum never leaves that module. I call such event for example "helper loop control event". The argument of this event is a typedef containing a string. That string gets connected to a case structure inside the event case in the helper loop. The event then get fired from MHL, whenever necessary, and carries (besides some other data) a string message to the helper such as GO or NGO or QUIT and the helper then acts accordingly. I ask this because I am always a little concerned about the requests getting inadvertently misused outside the given module. I am a bit worried however that my approach may violate the DQMH sanctioned module design rules and look like a hoaky hack. Please share your thoughts.

[Taggart]

The project I just inherited, every time the developer wanted a new case inside the MHL, he created a request event, even if the case was just used locally, ie called from another case of the MHL.   So first of all he exposed that ability to call that case now outside of the module...

On top of that inside the calling MHL case, instead of enqueing it, he fired off the request event, which now involves the EHL and if you want to occur one right after the other, now you've introduced the possibility of an event firing in the meantime.

Honestly what he really should have done, is make that case a subvi and just call it directly...

A great framework can't overcome poor design...

[Rafal_Kor]

The situation you've described is exactly what I'm trying to prevent, i.e. unnecessary exposure of the inner workings of my module, which "private request" kind of, sort of, do. Ok, so they are designated as private. In my mind simple designation as private may not be enough to prevent an external use of a request, unless there was some kind of mechanism in the module and/or the framework that would not allow the use of private requests outside of the module they are private to. Hence my question to Fab just above. In my mind the requests and broadcasts almost by definition imply "public use" as they represent the module's API. So that's how I feel about this, but I would really like to hear from the architects themselves, i.e. Fab and Joerg, because I'm really not in anyway LabVIEW certified.

[Taggart]

I guess my rule of thumb would be:

a case in the MHL should be associated with either a request event or should be enqueued from a helper loop... Otherwise that implies you are only calling it from another case in the MHL, in which case, you should just make it a subvi and call it in the other case.

[Taggart]

Another acceptable case would be if the MHL case is tied to a frontpanel event.

[Taggart]

My advice would be:

if you are thinking about a private event - why do you need a private event?  If all the event does is enqueue a message to the MHL and the only place it is called is in a helper loop, then I would suggest:

Pass the helper loop the queue and let it enqueue the message itself.  Cut the EHL out of the equation.  It adds no value. And the helper loop is already part of the module, so you are not really breaking encapsulation (at least at the module boundary) by passing it to the helper loop. 

It can also help to make your helper loop more reusable, because now it's not tied to your module.

That said if you make the vi that fires the private event a private "method" of the module (by right clicking on it in the project and marking it as private) nothing outside the module should be able to fire the event, unless you leak the event ref somewhere else, which DQMH shouldn't do, you would have to intentionally do that.

[Rafal_Kor]

Oh I see... so I guess the *.lvlib containing the module can be considered like a class, so that if something within it, is designated as private, it will not be allowed to get used anywhere else. And I guess if the module was wrapped in a class it would be an actor, and I purposely have been avoiding the use of actors as my projects are just not large enough to justify it. 

[Taggart]

yes.  exactly.

If you are interested in how the DQMH compares to the AF, you should check out:

https://youtu.be/4-dzdyYIPLU

In some ways they are actually quite similar.  They both follow the actor model.