Panel Open Event

[JackDunaway]

Create a Panel Open event.

Among other things, it would provide a clean entry point for guaranteeing Control References have been created, allowing for their dynamic event registration to prevent errors such as the following:

[AristosQueue (NI)]

In the meantime, use the FP.Open method and tell the window to open in the Hidden state, then you can acquire your control refnums without the panel being visible yet.

[tst]

I see the basic logic behind this, but can you provide an actual example where this would be useful? So far, I think I've always done one of the following:

1. Set the VI to open the FP automatically, so no need for this.
2. Set the VI's FP state before registering, similar to what AQ suggested, so no need for this.
3. Placed the FP in a subpanel before running the VI, so again no need for this.

[JackDunaway]

>> Placed the FP in a subpanel before running the VI, so again no need for this.

I like to do that the other way around - run the VI first, allow it to perform it's UI initialization, then notify the host when it's ready to be inserted. (This way, you do not see indicator/controls hustling around to reach their initial value/properties.) Alternatively, as AQ suggests, the host can run the VI with the FP hidden, then unhide the VI after receiving the "Ready to Insert" message. All good if you've got access to the host code.

Another scenario - currently, I'm writing plugins for an existing (locked down) framework that does not have this much initialization state granularity/two-way notifications, so it's guesswork when the FP actually is created and when it's been inserted.

[rgvdh@rdf]

I have an app where a user hits the button on the main control panel to select which of several running VIs will be displayed in a subpanel.  I want selected VI to know when it's popping up in the subpanel so I can force updates of graphs of system history.  Currently I have a control called "just opened" and set it to T when loading the VI into the subpanel.  It would all be a lot cleaner if I could use the above-described event case to trigger the "force redraw".

[TurboPhil]

Here's another use case for the FP.Open event:

I have a bunch of state machine VIs that I want to be able to "put to sleep" and "wake up". When the front panel is closed, the VI does not abort (it is a subVI in a larger application), but it does flush its local state queue and goes into idle mode. I can then reopen the subVI from the top level application, and update the state queue to resume normal operation. Currently, I do that with dedicated "queue handlers" for all of my subVI panels, but that means that I have to explicitly queue up the "Wake Up" state to get it going.

It would be awesome if I could have the VI sitting idle (without polling!) until the FP.open event is fired, then it can queue up with "Wake Up" sequence on its own.

The end goal is to save and load preferences for the top level application. I can query for all open front panels, save the list of VIs to file, then later if I load the preferences file, it can step through the list of VIs and use the FP.Open method (or property) to open each one by name. Much cleaner than having to explicitly manage the queue of each of those VIs!