DQMH zero-coupling modules like AF?

[Taggart]

oh and if you watch the dependency video I posted, you can achieve the state where a module doesn't know/care about its caller very easily just by carefully considering which messages are broadcasts and which are requests.

I should also add it is easy to verify this by running Antidoc.

[joerg.hampel]

---

@WavePacket wrote:

By static linking you mean that one module has the other's VIs within the block diagram right? And therefore appear in the dependencies dropdown as listed within the .lvproj?

---

Exactly.

And by calling dynamically, I mean opening a reference to a VI via its path and then using the Call by Reference function to execute said VI:

 

That way, we can reuse our generic modules in all our customer-specific applications - because they don't have any customer-specific modules as dependencies.

Edit: You can take a look at the implementation if you like, it's open source.

[Taggart]

No you would have to duplicate the entire module (both EHL and MHL) and then just switch out the class in the shift register and add the new message. 

So 90+% percent of the module is duplicated but its really just the messaging code/glue.

[WavePacket]

---

@Taggart wrote:

No you would have to duplicate the entire module (both EHL and MHL) and then just switch out the class in the shift register and add the new message. 

So 90+% percent of the module is duplicated but its really just the messaging code/glue.

---

Yeah, ok -- thx.

[ChrisFarmerWIS]

There are a few other object oriented LabVIEW frameworks (other than DQMH/AF) available, that might be worth you checking out.

I recommend weighing up the whole tool chain when you assess them.  ie. Community involvement on forums, online help/videos, proven use in applications, automated scripting tools to help create your application, testers, documentation tools, regular updates/improvements, etc. 

I encourage you to download a few of the frameworks and start playing around with them.  You'll soon work out which framework makes more sense to you, and gauge if it's a good fit for your applications.

[drjdpowell]

---

@ChrisFarmerWIS wrote:

I recommend weighing up the whole tool chain when you assess them.  ie. Community involvement on forums, online help/videos, proven use in applications, automated scripting tools to help create your application, testers, documentation tools, regular updates/improvements, etc. 

---

Be careful when comparing frameworks that you have reasonable metrics.  Automated scripting tools are usually only in frameworks with a lot of boilerplate code that needs to be scripted.  In other words, it counters a weakness of the framework.  Similarly, the extensive zero-coupling techniques of the Actor Framework are a result of the high coupling that occurs when one doesn't use such advanced techniques, which is a weakness of the Actor Framework, not a strength.

[joerg.hampel]

---

@drjdpowell wrote:
Automated scripting tools are usually only in frameworks with a lot of boilerplate code that needs to be scripted.  In other words, it counters a weakness of the framework. 

In my experience, automated scripting tools play a very important part in conveying to a team of developers how they're supposed to work with the code, and what the code should look like. Those tools help a lot with applying a common way of working.

Yes, automated scripting tools and little boilerplate code would be even better 🙂

[drjdpowell]

Code consistency is an important value of a framework, and scripting is a powerful way to get that.  Though that only goes as far as your scripting does; I doubt any of the "zero-coupling" or other techniques discussed in this conversation are part of DQMH's scripting tools.