DQMH cloneable module not inserting VI ref into subpanel

[Matt_AM]

Hey Fancy Folk,

I'm trying to have a cloneable module be able to have its FP be inserted into a subpanel.  I started with the basic DQMN cloneable module templated and I have added a round trip event where the request is just the module ID and the broadcast is the VI reference and module ID from the DQMH module.  

In the API tester for my module, I have the broadcast take the VI reference and insert it into the subpanel.

However, when I go to request the subpanel, the subpanel doesn't get updated but when I probe the line with various clones running and requesting the FP reference, I can see the refnumber updating to different values.  

I was wondering if anyone knew why I the subpanel isn't updating based on the VI ref being sent to the subpanel.  My best guess is that it has to do with how preallocated clones work, but I'm not sure.

Code is attached and I think it should have everything that you'll need to look at it.  Its written in LV 2015.

Thanks,

Matt

[Darren · Accepted solution]

You need to make 3 changes to your code:

1. Check the error out from the Insert VI method... that will tell you that you're getting error 1144... you can't insert a VI into a subpanel if its panel is already open (and all DQMH Main VIs are started, by default, with their panels "open", but in Hidden mode):


2. Make sure you close the Main VI panel before sending it to the caller to be inserted into the subpanel:


3. By default, DQMH modules attempt to hide their panels when they close. You'll want to disable this code in Handle Exit.vi, as closing the panel of a VI currently in a subpanel will also close the VI panel that owns the subpanel:


A couple of other notes for you:
- Consider having the DQMH module do the insert. If the calling code wants to insert a DQMH main into its subpanel, then maybe just send a request to the DQMH module and pass the Subpanel reference. Then the DQMH module can insert itself... no need for that code to be in the caller.
- You might get a wider audience of DQMH users if you post questions like these to the DQMH Discussion Forum instead of the LabVIEW forum.

[Matt_AM]

- Consider having the DQMH module do the insert. If the calling code wants to insert a DQMH main into its subpanel, then maybe just send a request to the DQMH module and pass the Subpanel reference. Then the DQMH module can insert itself... no need for that code to be in the caller.

---

I was going to, but this is going to be a template for modules that will be several layers down for larger projects.  I figured it'd be easier for my calling code to handle the VI refs or create a separate module to handle the VI refs than have the template handle the sub panel.  If this was meant for something smaller I was going to. I'm still pretty new to this style of architecture so to me, it makes sense for the caller to handle the vi referencing if its meant for something bigger whereas the module handling the sub panel would make sense for something smaller.  

I found this and this talking about DQMH and subpanels.  Funny enough, the first link goes over exactly what you recommended (sans point 3).  I thought that if I didn't wire the error cluster of the sub panel's invoke node and it threw an error, the generic LV error popup would have happened.  Since the pop up didn't occur, I thought that closing the FP of my module was going to be an issue since I didn't have the VI loaded.  Does DQMH load the FP of its module as hidden or is that standard for LV?

I also added a little checker to the FP close section that doesn't invoke FP.close is the FP's state is already closed.  I tried doing several insert VI refs to my API tester and I ran into an error saying that it couldn't close the module's FP since the FP was already closed.

Thank you for the help and recommendations!

Matt

[Darren]

---

@Matt_AM wrote:

---

I was going to, but this is going to be a template for modules that will be several layers down for larger projects.  I figured it'd be easier for my calling code to handle the VI refs or create a separate module to handle the VI refs than have the template handle the sub panel. 

---

In my experience with this type of design, and to agree with what you're saying, the VI that owns the subpanel generally decides who should be displayed in that subpanel. My suggestion doesn't contradict that approach... rather, there's really no need for any sort of VI reference management. When top-level decides to put a sub-module in a subpanel, it can just send a request to the sub-module, who only needs the subpanel reference, and can take it from there. If the top-level module has gotten to the point where it knows what to display in the subpanel, then any additional reference management seems redundant to me. Top-level code decides what to do, and sub-level code actually makes it happen. The approach I describe has worked well for me in the DQMH-based subpanel applications I've worked on in the past.

---

@Matt_AM wrote:

I thought that if I didn't wire the error cluster of the sub panel's invoke node and it threw an error, the generic LV error popup would have happened.

---

The feature you're referring to is Automatic Error Handling, which DQMH intentionally turns OFF on all its code (in the templates and in scripted code like new event VIs). The DQMH framework was designed in such a way that error propagation should be explicitly defined on the diagram. My personal belief is that Automatic Error Handling is a crutch and should be avoided in all situations.

---

@Matt_AM wrote: Does DQMH load the FP of its module as hidden or is that standard for LV?

---

When DQMH initializes a module, it will open the panel in "Hidden" mode by default. This is to ensure that the module is kept in memory, and also because there are certain behaviors in VI Server that require a front panel to be open. Note that this is code in the template that you can change (like I did in Handle Exit.vi above) when necessary.

[Matt_AM]

Darren,

---

---

In my experience with this type of design, and to agree with what you're saying, the VI that owns the subpanel generally decides who should be displayed in that subpanel. My suggestion doesn't contradict that approach... rather, there's really no need for any sort of VI reference management. When top-level decides to put a sub-module in a subpanel, it can just send a request to the sub-module, who only needs the subpanel reference, and can take it from there. If the top-level module has gotten to the point where it knows what to display in the subpanel, then any additional reference management seems redundant to me. Top-level code decides what to do, and sub-level code actually makes it happen. The approach I describe has worked well for me in the DQMH-based subpanel applications I've worked on in the past.

When removing a VI from a subpanel, do you just need to run the invoke node to remove the VI and not have to worry about references?  I'm new to subpanel design and best practices associated with it. 

Upon thinking about what you said and my knowledge, I don't see why I'd need to pas the VI ref of the cloneable module "up the chain" when I can just pass the subpanel ref "down the chain".  Either way, the calling code would be the one handling the insert/removal, its just who do I want to be responsible for inserting the VI?  It's starting to sound like a request to the sub module to insert itself is a lot less design work.  The original method is to send a request for the VI ref then listen to the broadcast to insert into the sub panel, which requires 2 places to write code (the request then the broadcast).  Your suggested method sounds like its just a request for the module to insert itself, so its only 1 place to write code (the request).  Either way, the caller VI would also be the one in charge of making sure the panel has the proper VI inserted and removed.  

Matt

[Darren]

Yes Matt, it sounds like you and I are on the same page. As for VI reference management, it's unnecessary because the sub-modules would be using the 'This VI' reference on their diagrams to insert themselves into the subpanels, and these "self" references of VIs do not need to be closed, they are automatically cleaned up by LabVIEW.

For more information on which kinds of references need to be closed vs. which ones are ok for LabVIEW to take care of, check out my Brainless LabVIEW presentation, slides 24 through 26. If you're watching the video linked there, the relevant part starts at 29:25.