Generic/dynamic events, huh? Paging Joerg Hampel, please pick up the nearest white courtesy phone.

[DoctorAutomatic]

I've been looking through the HSE application template and the Wiki documentation, and for the life of me I can't figure out how or if what is happening there is that module A is able to receive a broadcast without being aware that a module B has launched. At least that's what I thought is supposed to happen. Am I wrong about this being the goal of the "system message"?

Even if I am wrong, I still can't figure out how Module A can send a broadcast to Module B without without explicitly registering for Module B's events. What dark magic is this? 

I'm sure it is documented somewhere but my brain is exhausted looking for it at the end of the day. Would appreciate a pointer to some info that goes into detail specifically about these default broadcasts like "system message" in the HSE template.

[esodar1981]

Hello,

didn't know exactly how HSE appication template works, but in order for module B to receive broadcast messages sent from A, module B MUST register for module A events... not the opposite.

[joerg.hampel]

---

@DoctorAutomatic wrote:

Paging Joerg Hampel

---

https://www.youtube.com/watch?v=lj9FVlEtknU 

Hello and thanks for looking at our HSE Windows Application Template!

1. The "System Message" broadcast is meant to work exactly as you say: A way for modules to share a common, generic communication channel, which makes it possible to register for another module's broadcasts programmatically. Most of our template's framework functions (like "show module in sub panel") are implemented by using System Message broadcasts. 

2. Our Application Template serves as a generic starting point for our applications, so it makes sense to try and separate generic framework code from project-specific modules. That is the main reason why our template reads a list of (said project-specific) modules from a configuration file and then loads those modules dynamically (i.e. without static linkage, but via finding the modules and their member VIs on disk / in memory)

3. In order to communicate between those modules and the rest of the framework, we make use of the System Message broadcast. Seeing as all modules implement this same broadcast with an identical datatype, we can register for those broadcasts dynamically! There are really only three things to this:

3.1 In the module registering for the broadcast (eg module A), wire the datatype of the broadcast (in our HSE case, an array of "System Message" event references) to the event registration node outside the event structure to set up the data type of the events at development time

3.2 Implement a VI for all modules which want to send broadcasts (eg modules B-E) that returns this System Message event reference (see HSE DQMH Flavour in our dokuwiki for details)

3.3 From module A, call that VI mentioned in 3.2 dynamically for modules B-E, and then register for that event by sending the event reference to the module A's EHL and updating module A's EHL event registration.

I've thrown together a quick collection of screenshots in our dokuwiki detailing the series of steps for doing all this. There's no textual description, but you should be able to follow the steps directly in the source code:

https://dokuwiki.hampel-soft.com/code/dqmh/hse-application-template/startupvi 

Let me know if this clears things up!

[DoctorAutomatic · Accepted solution]

---

@joerg.hampel wrote:

---

@DoctorAutomatic wrote:

Paging Joerg Hampel

---

https://www.youtube.com/watch?v=lj9FVlEtknU 

Hello and thanks for looking at our HSE Windows Application Template!

1. The "System Message" broadcast is meant to work exactly as you say: A way for modules to share a common, generic communication channel, which makes it possible to register for another module's broadcasts programmatically. Most of our template's framework functions (like "show module in sub panel") are implemented by using System Message broadcasts. 

2. Our Application Template serves as a generic starting point for our applications, so it makes sense to try and separate generic framework code from project-specific modules. That is the main reason why our template reads a list of (said project-specific) modules from a configuration file and then loads those modules dynamically (i.e. without static linkage, but via finding the modules and their member VIs on disk / in memory)

3. In order to communicate between those modules and the rest of the framework, we make use of the System Message broadcast. Seeing as all modules implement this same broadcast with an identical datatype, we can register for those broadcasts dynamically! There are really only three things to this:

3.1 In the module registering for the broadcast (eg module A), wire the datatype of the broadcast (in our HSE case, an array of "System Message" event references) to the event registration node outside the event structure to set up the data type of the events at development time

3.2 Implement a VI for all modules which want to send broadcasts (eg modules B-E) that returns this System Message event reference (see HSE DQMH Flavour in our dokuwiki for details)

3.3 From module A, call that VI mentioned in 3.2 dynamically for modules B-E, and then register for that event by sending the event reference to the module A's EHL and updating module A's EHL event registration.

I've thrown together a quick collection of screenshots in our dokuwiki detailing the series of steps for doing all this. There's no textual description, but you should be able to follow the steps directly in the source code:

https://dokuwiki.hampel-soft.com/code/dqmh/hse-application-template/startupvi 

Let me know if this clears things up!

---

YESSS! I'm sure this info is somewhere in the extensive documentation you've made public but for some reason it didn't "click" for me until reading your reply just now. It makes complete sense to me now. 🛐 I was looking for a "bowing down" emoji, this was the closest I could find. Thank you for all the stuff you've made available publicly, without people like you and Fab my Labview abilities would be a whole lot more pedestrian.

While I have your ear, one more question. I've noticed you specifically mention that the way you/HSE begin projects is by the simple act of copying your template project structure. On the other hand, it seems like for others they go the route of making some sort of fancy template type of thing that one selects in the "New..." menu and all that, with fancy icon and description. It seems that you specifically prefer your method (or maybe I'm reading waaaayy too much into it). I actually prefer your method a lot, i'm not even sure why and couldn't articulate why or what the difference is. I'm curious what your reasons are for your preference to just simply copy the whole template to start a new project. Like I said, it's the most intuitive solution to me as well but other than that I wouldn't be able to say why it's preferred.

[joerg.hampel]

---

@DoctorAutomatic wrote:
I've noticed you specifically mention that the way you/HSE begin projects is by the simple act of copying your template project structure. [..] I'm curious what your reasons are for your preference to just simply copy the whole template to start a new project. 

---

The reasoning for using our template the way we do is not half as elaborate and sophisticated as you'd imagine...

1. We don't create new projects on a daily basis, so never felt the need for more automation.

2. Our team is small, our customers near and dear, so there's usually not much communication or training needed for that specific part - starting a new project - and hence no driving (business) force for a more streamlined process.

3. Maintaining a template on its own needs some effort, whereas our template application repository serves as the place for developing new features, doing the testing, and at the same hosting the template as reuse code - all at the same time.

4. Creating a template for integrating with LabVIEW's "New..." dialog would take a bit of effort due to our way of managing our HSE-specific dependencies (i.e. how we keep as much as possible inside the repo/project structure), it's not 100% straight forward.

5. It just works very well for us. Using the released "package" (a zipped source distribution created through our automation toolchain) together with the setup tool just does the trick for us very nicely.

With all that being said, I can totally imagine creating a nicer DX for those users preferring a "New..."-wizard kind of experience in the future. At the moment, that is not a priority, though: We're currently conducting a survey for our HSE open source offerings, and the first results indicate that installation/setup is not perceived as a pain point. 

Pie in the sky: We're still evaluating VIPM / Project Dragon as a means of installing dependencies as VI packages into our project directories (currently waiting for the latest version of VIPM). If and when that works well enough for us, we might consider converting all our zip-archive packages into VI packages and switching to VIPM. That might solve some of the linkage problems we currently face when creating project templates...

[joerg.hampel]

PSA: Half a year later, we have released a project wizard for creating new projects based on our HSE Application Template. You can find it here:

https://www.vipm.io/package/hse_lib_hse_application_template_wizard/

I have to admit that this wizard makes it so much easier to start a new project for anybody not working with our reuse libraries on a daily basis. So please go and check it out and let us know what needs improvement!