DQMH Consortium Toolkits Discussions
Automatically create a subvi when creating a new Event
@Olivier-JOURDAN wrote:
Hi @hallo2014,
When I started using DQMH, I tend to do the same, but quickly I found it wasn't beneficial.
First, I found out that name of the wrapper was often really close to the request. So having a meaningful name for it was not easy.
Second, I find it made the code less readable as far as you needed to open the wrappers to see what the code was doing.
My current way to do this is to code most of the code in the MHL request case. I can create subVI to implement the request, but they are just using the data they need from the module data cluster.
I'm curious to hear from other DQMHers 🙂
The naming conflict thing can be solved fairly easily with namespacing by making a class, putting it in the module private data, and switching out the DQMH module data type def with the class constant, AKA making state data into a class as suggested in Simple DQMH Dos and Don'ts. But then, that means wiring the whole class wire into the methods which is just what joerg recommended against.
@OP, it all depends on what your module does really. I've only fully made an instrument driver DQMH module to this point, and for that the process was fairly simple and I did exactly what I just described. I've made a database module template as well, and that as well will use class data as state data.
But once I get to actually making a full fledged project, I would say that for my controller or GUI modules, I'm currently leaning towards not using class data and instead just making the MHL cases simple and possibly expanding the case structure just a smidge to give myself a bit more room to work.
@hallo2014 wrote:
By using just one "wrapper" Subvi for my actual business logic, it does not require the touch the main DQMH case structure and just use the subvi instead (which of cause has many other decoupled sub-vis).
You can still do that, without wiring the entire "Module Data Cluster" as input and output of the SubVI. Just unbundle from the cluster what the subVI needs to do its thing, and wire them as individual controls to it. Then if the subVI changed the state of anything, put it as an indicator and wire it to a bundle. A couple extra minutes for each subVI to save you hours or possibly days of debugging. That's how I'm gonna approach it anyway.
Edit: but to answer your question about making a subVI automatically be created whenever you make a request, there might be some scripting you could finesse to do it, but if it is automatically created the VI name would need to be created automatically but can't be the same as the request. I have the most basic knowledge of scripting, enough to fix small things on a folder of VIs, so can't help you there. It's a business decision, weighing the time taken to make all that scripting code vs the collective extra time taken to manually make each subVI.
@FireFist-Redhawk wrote:
The naming conflict thing can be solved fairly easily with namespacing by making a class, putting it in the module private data, and switching out the DQMH module data type def with the class constant, AKA making state data into a class as suggested in Simple DQMH Dos and Don'ts. But then, that means wiring the whole class wire into the methods which is just what joerg recommended against.
We had a great discussion about this very topic with our DQMH Trusted Advisors some time ago, after which Sam updated his very helpful Dos and Don'ts article accordingly (thanks Sam!):
