SubVI for events code in the MHL

[LabVIEW-Surfer]

In our current practice, we encapsulate the content of DQMH MHL events within subVIs to maintain a tidy diagram and especially to facilitate the seamless propagation of changes to similar projects that use the same implementation. 

I think It would greatly benefit the DQMH framework if it could autonomously generate these subVIs as part of its MHL event scripting process.

Current situation:

Expected situation:

[joerg.hampel]

Hello LabVIEW-Surfer, thank you for using DQMH and for taking the time to share your ideas for improving the tool!

The question of how to keep code in the MHL case structure is being discussed regularly, and different teams usually pick varying strategies to make DQMH work for them. 

If you read through the Simple Do's and Don'ts, you will see advice to "Do make every MHL case a subVI" and "Do consider making state data a class". You'll also see that those two recommendations have been augmented with clarification.

There are downsides to making every MHL case a single subVI (*):

- you hide the actual implementation of the request, which makes it more difficult to see at a glance what's going on

- you link the subVI to the very DQMH module because you wire in/out the data cluster typedef, which makes it impossible to reuse these VIs outside the module 

(*) The same goes for changing the data cluster into a class and making each request MHL case a method of the class.

The recommended approach would be to keep the code tidy, but create those subVIs manually in a way that they

- do not include any framework code (eg the Variant to Data + request typedef) as this will remove any static linking (coupling) to the module itself

- have a very clear API (meaning you only unbundle/bundle the data you actually need in that specific MHL case)

I hope that my explanation makes sense, and I'm curious to hear your opinion.

J.

[LabVIEW-Surfer]

Hi Jörg,

Thanks for your prompt reply!

I agree that the MHL SubVI should not include the in/out data cluster typedef but only the data you actually need in that specific MHL case, in order to have a clear API with the least coupling.

I would still suggest having the option of automatically generating a SubVI for the MHL code when creating an event. This could be a checkbox in the "Create New DQMG Event" wizard.

Br. Elio

[Taggart]

If we are expecting users to write code in the MHL, we should facilitate that by making it reasonably sized. It is miniscule. One of the first things I do is expand it.

[Olivier-JOURDAN]

About the MHL size, this idea has been accepted 🙂

[AgentBK]

I support the suggestion to optionally have the scripting process create subVIs for events in DQMH.

I understand that there are valid concerns about hiding the implementation details, but I believe that it can make the code tidier, more testable, and enhance teamwork. As LabVIEW-Surfer mentioned, having an option to choose whether to create a subVI or not could be a nice balance between these considerations. Personally, I tend to lean towards the subVI approach most of the time.

Regarding the argument against linking the subVI to the DQMH module, reusability is not the primary goal. Clean and uncluttered code within the module as well as better teamwork is. Developers can always create separate classes or libraries if they need reusable components. Event SubVIs would allow for greater flexibility and teamwork without worrying about merge conflicts.

Regarding the recommendation for a clear API for the subVI, I completely agree. Defining a concise API that unbundles/bundles only the necessary data for a specific MHL is crucial and I believe that the developers already put thought into it when creating a new event. The subVI should serve only as a container for executing the code related to that event, therefore its input and output data types should align with the scripted API. Data cluster/class could optionally be added. Either way, developers should be allowed to modify the inputs and outputs of the subVIs to suit their needs.

I truly hope this feature gets to see the light of day 🙂