Why isn't Load Module In Subpanel a default event in DQMH?

[littlesphaeroid]

No sooner did I write my first DQMH module than I discovered I would need to load it into a subpanel. But this is not available out of the box. I know there's an MGI template for this, but the MGI solution feels overly complex, and anyway, I wanted to learn how to do it myself.

So, I created an event with a subpanel reference input. Then I discovered that the panel open/close events (and some others) are actually handled in Event Handler Loop. This seems to contradict the general style put forth for DQMH, that the EHL should be used only as a passthrough for messages to the message handling loop, where all action should take place. I started, therefore, by moving these events to the MHL, so I could modify those functions to act on my subpanel, whose reference would be part of the the MLH state data. This is because if you need to unload the module from the subpanel (on exiting the module, or opening its FP in a separate window), you need to the subpanel reference to remove the running module from it first.

This worked. 

But then, I was watching a video presentation about DQMH and learned that the show and hide panel events are handed in the EHL to keep those functions responsive, in the case where the MHL might be busy doing something else. Soooo.... I rewrote my template to hold the subpanel reference in the EHL. Got it all working for both singleton and cloneable modules, and came here to see if there is some reason why loading into a subpanel this is not part of the default modules and testers.

Thoughts?

[Gregory]

You can request new features here: https://forums.ni.com/t5/DQMH-Consortium-Toolkits-Feature/idb-p/delacor-ideas

And if this is something you plan on using in a lot of modules, you should build it into a template so that you can re-use it later.

[Ozfarmboy]

We also have this request in our templates.

[joerg.hampel]

---

@littlesphaeroid wrote:

came here to see if there is some reason why loading into a subpanel this is not part of the default modules and testers.

---

Hey @littlesphaeroid, thanks for giving DQMH a try and sharing your experiences and questions with us!

As Greg already said (thanks Greg!) please feel free to add this as a new feature request.

I can think of many reasons why this isn't part of the framework:

- it never occurred to us (the Consortium) that this should be a native citizen of the framework

- nobody has created a feature request for it so far

- implementation details might vary widely depending on who you ask (*)

At HSE, our HSE Application Template (a free and open-source project, in case you're interested) handles this slightly differently:

- The UI Manager module contains the subpanel and has control over which other modules can be displayed, and when

- The modules need to share the reference to their main.vi with the UI Manager if they want to be displayed

- The UI Manager has to request a module to be displayed

This design allows control in two places: Is a module ready to be displayed? And is the application ready to change the display?

As you can see, a generic "Show in subpanel" request would not help us a lot... 🤷‍♂️

[littlesphaeroid]

Thanks for the replies. The way I see it, "show/hide panel" is probably not that useful for most modules outside of testing, and is included, and I feel like "load in subpanel" is more likely to be widely useful.

It sounds interesting to have a separate module to handle subpanels (sounds interesting band another thing to learn on top of the framework), but for making DQMH more useful out of the box, loading in a subpanel makes a lot of sense to me. I could even see having the add module dialog offer a set of options to include this capability, as it does not with the "do something" examples.

[JoGra]

I really like the MGI Panel Manager and we recently updated the DQMH Templates: Moore Good Ideas / LabVIEW Tools Network / DQMH Panels · GitLab

Unfortunately the VIPM package is not updated yet, but its also not that much code to add manually.

It adds simple API to setup the "Panel" and a  request "Change Panel":

[drjdpowell]

As a non-subpanel aside, OP's problems are an example of why the EHL-MHL design, so common in LabVIEW, is an Anti-pattern, something that seems like a good idea but actually causes far more problems than it's presumed advantages.   Poor OP had to:

1. Learn the rules to minimize the problems of the anti-pattern: "the EHL should be used only as a passthrough for messages to the message handling loop, where all action should take place"; no state data in the EHL.
2. Learn the exceptions: Oh, except responsive UI stuff like subpanels
3. Deal with the inconstancies: EHL now needs state data (the subpanel ref)