Luis,
Thanks for sharing DQMH with your user group. You mentioned in an email to me that there were two questions that you would like for me to expand on, so here are my comments.
1) Difference between Singleton and Cloneable in terms of memory, efficiency and why DQMH has Singleton if it is possible to create a Cloneable with the Singleton behavior.
You can read more about the difference between Singleton and Cloneable in the DQMH Documentation.
The existence of the Singleton module is two-fold:
- Simplicity: It is a lot easier to explain how DQMH modules work using the DQMH Singleton module. Managing the clone IDs add extra complexity to the code. If all the programmer wants is a module that is accessible in different parts of their program, they can call Start Module.vi as many times as they want and they will always get the same instance.
- For most applications, that is all is needed: We found that in the majority of applications using DQMH, programmers were using only Singleton modules with only a few instances requiring the Cloneable modules. When we discovered that programmers were getting into a situation where they would have wished the module was cloneable, we added the feature to be able to run Cloneable modules as singletons.
Blackburnite also made some good observations on his post above regarding the differences. Blackburnite said "Modules themselves do confirm back that they have started as a part of the framework however the one caveat is that this is done as a part of the module Main.vi which means a user could conceivable remove this functionality if they did not know what it was for."
There are several things in the Main.vi that could cause the module to not behave as expected, however, we expect that LabVIEW programmers will be using the DQMH API Tester to launch and test their code. The scripting tools even encourage the programmer to keep their DQMH API Tester up to date. A DQMH out of the box does three things very well: "Starts when we tell it to start and reports back immediately, reports errors to DQMH API Tester (or stops in error if running as a stand-alone), stops graciously and immediately". If the DQMH module stops doing any of those three things, then it is something the programmer just did. Running the DQMH API Tester after each new event has been created or new features have been implemented will ensure that the programmer would know immediately that they removed something they shouldn't have removed.
2. Why DQMH is not LVOOP based?
We decided to limit the LVOOP to be done inside the DQMH module. Our main objective was to make DQMH accessible to teams with different levels of proficiency. This includes teams where some programmers are not familiar and do not want to become familiar with LVOOP. This allows the programmers who do want to use LVOOP and are comfortable with LVOOP to use it inside the module itself and provide a public API that does not contain any LVOOP at all.
For other ways to combine LVOOP and DQMH, check out the HAL post at the Delacor blog. Also, I gave a presentation at NI Week with some other tips and tricks for DQMH projects and there is a section (tip 5) where I describe other ways LVOOP can be used with DQMH.
DQMH also has a feature where LabVIEW programmers can create their own DQMH Module Templates and still take advantage of the DQMH scripting tools, the shipping example of a module template replaces the local data with an object.
It was never our intention to have everyone use DQMH. We understand that every team is unique and have their own needs. If the entire team is comfortable with LVOOP and work most of their time in LabVIEW, then Actor Framework might be a better option for that team. If a team has their own framework and it works for them but they would like to add some automation for the repetitive tasks as we have done, we would be more than happy to help them get there.
If you want to discuss DQMH more, please visit the DQMH forum.
Regards,
Fab
