Add 'Insert into Subpanel' and 'Remove from Subpanel' requests to standard DQMH module templates

[Darren]

Over the years I find myself adding the following two requests to my modules more and more frequently:

The MHL code for these requests is very simple, and it doesn't get in the way for modules that don't interact with subpanels. I think these requests should be added to the standard singleton and cloneable templates.

I am familiar with the "create your own module template" argument against ideas like this. I've made those same arguments before. And I've implemented my own module templates with these requests before. But present-day, I equate the utility of these subpanel functions with the utility of existing core requests like 'Show Panel', 'Hide Panel', and 'Show Diagram'.

In addition to adding these requests to the core templates, we should also add a subpanel to the API Testers to (1) be able to test these requests (obviously), and (2) demonstrate the ease with which a DQMH module can be integrated into an existing subpanel-based UI.

[Photon_Dan]

Just as soon as LabVIEW Real Time stops being so allergic to the slightest mention of a Subpanel... I'm all for it!

[Darren]

According to the LabVIEW Help, the Insert VI method of the Subpanel class is supported on LabVIEW Real-Time. If there are known issues with calling Subpanel methods, those could be wrapped in subVIs with conditional disable structures. If there are known issues with having the module main VI local data cluster contain a subpanel reference, that's a more serious issue that I would have expected somebody to file a bug report to NI about by now.

I tried creating a subpanel (and a subpanel reference) in an RT VI and the VI did not break. I don't have a target to deploy to... Dan, are the issues you're referring to related to deploying a seemingly runnable VI that contains a subpanel and/or subpanel reference in it?

Back to the idea... some people prefer an approach where the VI that owns the subpanel gets a reference to the DQMH module main VI, and then does the subpanel insertion itself. I don't like this approach because it requires writing the insertion code in the caller, compared to having everything already there in a module template.

A DQMH module should decide to insert itself into a subpanel (remember, we call them "requests" for a reason). I don't like the idea of passing a DQMH Main VI reference around for calling code to do whatever it wants with it.

[MichaelAivaliotis]

I've added these to my own DQMH template a long time ago and would love to see this built into the main template so others can enjoy the benefits out of the box.

I'm curious how you intend to do the unembed without the subpanel ref.

[Darren]

> I'm curious how you intend to do the unembed without the subpanel ref.

Store the subpanel used for the insert in the module local data, and use the stored reference for removing it.

[drjdpowell]

Just to give my experience with a competing framework (Messenger Library):

• I have the equivalent of your "Insert into subpanel" message built-in to the template.
• I have never even thought of having a "Remove from subpanel" message and am confused as to why you would have that.
• I often switch, in practice, to passing the VI ref to the caller to handle inserts.   Usually this is because the caller is mimicking at Tab with multiple VIs that share one subpanel, and that works much better than if the Caller holds an array of VI references and is the only one controlling the subpanel.

[Olivier-JOURDAN]

+100 😀

I have my own template implementing the feature as you described.

Concerning the "remove from subpanel", I'm not using it often, but in some situations I need it.

[joerg.hampel]

I prefer to keep all subpanel-related code in the module that actually has the subpanel on its front panel. That's how we do it at HSE, and how it's implemented in our HSE Application Template: The UI Manager module decides when to insert which module (the module can ask to be inserted, of course, and will send its VI reference with that request)

Having those additional two requests added to the default templates does not break anything for us, I guess, so I'm not actively against this request.