Naming of MHL case subVIs

[Jens_S]

Hello!

I'm using DQMH 5.x for quite a while now and so far I'm pretty happy with it besides one thing. If you follow the "Simple Dos and Don'ts" you should create a subVI for each MHL case which I totally agree with.

Let's say we have a request called "Start Test". The scripting tools do most of the work creating the necessary files, EHL and MHL case and so on. If you now want to add the subVI for the MHL case and name it "Start Test.vi" (because this would be the most reasonable name for it) you can't do this because the VI for the request itself is already using this name.

What I do now is trying to find a suitable name for the subVI that is not totally off and still provides enough information so you can assume what the VI does. Wouldn't it be convenient if the automatically generated VIs would have some kind of suffix/ prefix like "Start Test - Request.vi" so we can use the event name for our own VIs and don't have to mess around with the file names?

I would love to know how you do this in your projects?

Best regards
Jens

[joerg.hampel]

We would usually call them "Start Test--helper.vi" if nothing else comes to mind in terms of better naming...

[Darren · Accepted solution]

I've also used MHL - Start Test.vi. And all those subVIs go in an MHL virtual folder in the project so I can find them easily.

[joerg.hampel]

---

@Darren wrote:

I've also used MHL - Start Test.vi. And all those subVIs go in an MHL virtual folder in the project so I can find them easily.

---

Thanks, Darren - much better. We already put any VI that we create manually into a separate (virtual) folder, so that aligns pretty well with our current WoW.

Thinking about it now, I feel like this is more of a corner case for us: To have exactly one VI that does everything inside one MHL case.

[Darren]

---

@joerg.hampel wrote:

Thinking about it now, I feel like this is more of a corner case for us: To have exactly one VI that does everything inside one MHL case.

---

I agree, it doesn't come up too often. I can only think of one module off-hand where I took this approach.

[Jens_S]

Thanks for your comments.

I like the idea with the naming even though I might stay with putting all the "custom" VIs in a separate virtual folder and arrange them in sub folders by function or something like this. Most times the subVI for the MHL case is just a "container" for all the other VIs that are often used in several different cases so putting them in a case specific virtual folder wouldn't be too useful.

[T.L.]

Hi Jens,

i always replace the cluster in the MHL by a class private for that module. This class provides a separate name space and allows to name the vi with public access scope to have to same name as the MHL case and the event. The class gets its own subfolder inside of the DQMH Folder structure where i put all vis belonging this class into.

best regards
Thomas

[FabiolaDelaCueva]

---

@T.L. wrote:

Hi Jens,

i always replace the cluster in the MHL by a class private for that module. This class provides a separate name space and allows to name the vi with public access scope to have to same name as the MHL case and the event. The class gets its own subfolder inside of the DQMH Folder structure where i put all vis belonging this class into.

best regards
Thomas

---

You could also make the class part of the local data cluster and separate what is "GUI" or DQMH related to what is class-related. For example, updating the status on the front panel may be more GUI related and have nothing to do with the Device object in that module. I like to make that distinction. That also means I can share my classes with others who are not using DQMH. We also have used DQMH just as a tester for a class before we give the class to the customer.

[T.L.]

Hi Fab,

this is my typical approach:

I have a class for operating with my device. 

This Class is used by my worker DQMH modules internal private class. 

Finally I separate my UI by using MGI's DQMH Panel Manager (https://www.mooregoodideas.com/products/panel-manager/index.html) from my DQMH module operating with the device. This UI uses only public API and Broadcasts of worker module and some code needed for representation and controls handling. 

best regards

Thomas

[Gregory]

Sorry to revive an old thread, but this has come up a couple times for me recently. I've been making a library called SubVI.lvlib underneath the module library.

This has to go in its own folder on disk so that the VI names don't conflict with the Request API names. So far this has been working fine for me, but I also like the idea of using "MHL--" as a prefix in the future.