Register for event on VI that's not open

[BertMcMahan]

---

@raphschru wrote:

OOps "Window Opened" is a private event which is not accessible with a standard LV config (and not recommended to use).

Since you cannot detect the opening of the front panel with an event, you will have to pass a command (using a message queue) to the background VI right after you insert it in the subpanel to make the registration.

Concerning the array of buttons done by hand, you could also iterate through the Controls[] property of the Front Panel and filter only the needed controls (by class or name).

---

I think Panel Resize might catch this. It returns a "Previous state" parameter. I haven't tested it but it'd be worth a shot.

[raphschru]

I have tested, "Panel Resize" does not catch when you open/close the front panel or insert/remove it in/from a subpanel.

It only catches when you resize by hand, minimize/unminimize, maximize/unmaximize.

[johntrich1971]

---

@BertMcMahan wrote:

---

@raphschru wrote:

OOps "Window Opened" is a private event which is not accessible with a standard LV config (and not recommended to use).

Since you cannot detect the opening of the front panel with an event, you will have to pass a command (using a message queue) to the background VI right after you insert it in the subpanel to make the registration.

Concerning the array of buttons done by hand, you could also iterate through the Controls[] property of the Front Panel and filter only the needed controls (by class or name).

---

I think Panel Resize might catch this. It returns a "Previous state" parameter. I haven't tested it but it'd be worth a shot.

---

You could send a user event to the vi when you insert it into the subpanel and register your controls event inside the event structure.

[playerm1 · Accepted solution]

---

@Basjong53 wrote:

---

@UliB wrote:

Put an invoke node 'Front Panel.Open' before the event registration and set the state to hidden. The front panel will open, but not visible for the user. If you want to show the panel to the user use the same invoke node with 'Standard' for state.

---

Thank you for the suggestion, this does work. However, what if I want to show the background VI in a subpanel? Setting the FP.Open methods to Standard opens a new window, not in the subpanel.

---

Prior to inserting the VI into a subpanel, use the VI property node "Front Panel Window: State" (read) to check for the "Hidden" state.  If "Hidden", use the same VI property node "Front Panel Window: State" (write) to set the front panel state to "Closed".  You should then be able to use the subpanel method "Insert VI" without the background VI opening separately.

[BertMcMahan · Accepted solution]

---

@raphschru wrote:

I have tested, "Panel Resize" does not catch when you open/close the front panel or insert/remove it in/from a subpanel.

It only catches when you resize by hand, minimize/unminimize, maximize/unmaximize.

---

Good info to know. In that case I'd consider using MGI's Panel Manager (https://www.mooregoodideas.com/products/panel-manager/). I double checked and you do get an event when you show a panel. It's a bit hard to find though as the palette doesn't include all of the functions you need, but it's in the example under "Panel Events.vi". Open "Event logger.vi" and you'll see how they're using the Panel Helper to register for some events, one of which gets fired when you Show the panel.

(Note this is an event configured by the toolkit, not a wrapper around built-in functions, so it doesn't catch when you use VI Server to show the panel. You use the "Show" function that's part of the toolkit instead. It just encapsulates all of the manual User Event creation that others have recommended in this thread).

[UliB]

---

@Basjong53 wrote:

---

@UliB wrote:

Put an invoke node 'Front Panel.Open' before the event registration and set the state to hidden. The front panel will open, but not visible for the user. If you want to show the panel to the user use the same invoke node with 'Standard' for state.

---

Thank you for the suggestion, this does work. However, what if I want to show the background VI in a subpanel? Setting the FP.Open methods to Standard opens a new window, not in the subpanel.

To open the front panel in a subpanel is exactly my use case.

I open the front panel in hidden state, then I register the events and I close the front panel again just to insert the VI in a subpanel . But if there is no active reference to the VI or the VI is not on a block diagram as SubVI, the VI will be removed from memory and you can not insert it in a subpanel anymore.

What do I do? I have a FGV in which I hold my references to the VIs I want to insert in a subpanel, so I keep the VIs in memory when I close the front panel.

[Basjong53]

---

@johntrich1971 wrote:

---

@Basjong53 wrote:

---

---

I have to make the array anyway to determine which of the buttons has been pressed. I seach the ctlref in the array of button references.

---

That's one of the nice things about the event structure - it reports a control reference for the control if the control reference is needed, and if there are multiple controls for that event it will only return a reference for the control that triggered the event. 

Edited to add: I just reread your response. I'm not following why you need to search the array. Do you have a case structure inside the event structure that runs different code depending upon the control? Perhaps you could use the control name instead of an index in the array. This would be more scalable and easier to read in the future.

---

Yes, I wrote some Rube Goldberg code. I can just use the ctlref directly.

---

@playerm1 wrote:

---

@Basjong53 wrote:

---

@UliB wrote:

Put an invoke node 'Front Panel.Open' before the event registration and set the state to hidden. The front panel will open, but not visible for the user. If you want to show the panel to the user use the same invoke node with 'Standard' for state.

---

Thank you for the suggestion, this does work. However, what if I want to show the background VI in a subpanel? Setting the FP.Open methods to Standard opens a new window, not in the subpanel.

---

Prior to inserting the VI into a subpanel, use the VI property node "Front Panel Window: State" (read) to check for the "Hidden" state.  If "Hidden", use the same VI property node "Front Panel Window: State" (write) to set the front panel state to "Closed".  You should then be able to use the subpanel method "Insert VI" without the background VI opening separately.

---

Very good suggestion! Thank you.

---

---

---

@BertMcMahan wrote:

---

@raphschru wrote:

I have tested, "Panel Resize" does not catch when you open/close the front panel or insert/remove it in/from a subpanel.

It only catches when you resize by hand, minimize/unminimize, maximize/unmaximize.

---

Good info to know. In that case I'd consider using MGI's Panel Manager (https://www.mooregoodideas.com/products/panel-manager/). I double checked and you do get an event when you show a panel. It's a bit hard to find though as the palette doesn't include all of the functions you need, but it's in the example under "Panel Events.vi". Open "Event logger.vi" and you'll see how they're using the Panel Helper to register for some events, one of which gets fired when you Show the panel.

(Note this is an event configured by the toolkit, not a wrapper around built-in functions, so it doesn't catch when you use VI Server to show the panel. You use the "Show" function that's part of the toolkit instead. It just encapsulates all of the manual User Event creation that others have recommended in this thread).

---

I will have a look at MGI's Panel Manager. I'm already using the Actor framework for this application. So it seems a good library to use in my projects! Thank you for the suggestion!

[BertMcMahan]

Ah perfect. Its integration into AF is quite good. I use it on 100% of my AF projects and it's probably my most used external toolkit. Post up (probably in the AF boards) if you're having any trouble getting the hang of it. There was a fairly steep, but short, learning curve right at the beginning, then everything clicked and it was smooth sailing after that.

There's a merge VI in the standard palette to plop in your Actor Core that provides user events with subtypes of Initialized, Shown, Hidden, etc. Works great.