LabVIEW Idea Exchange

Showing results for 
Search instead for 
Did you mean: 

Allow Event Registration when FP is closed

Status: New

There are a lot of issues that arise because you can't register for events using control references when VI's front panel is not open. Here is a practical example that illustrates a bunch of limitations:


  • We have a multi-window application, and most of the windows can be opened/closed on demand.
  • We want to be able to handle common user interactions on all windows--in particular, we have common right-click operations for all indicators on all windows.
  • We would like to have a single daemon that registers all indicators for right-click events
    • Ideally, each window VI would send it a list of applicable control refnums on initialization, and it would handle registering for events from all
    • (This will, of course, require some redundant registration, as you cannot append items in a registration--but I can understand why...)

The problem, however, is that we can't register for such FP events when the FP is not open. So that means we have to have an "Open FP" state in our simple state machines (if only there was an FP.Open event! but that's a separate idea...), and register for these events on first call in that state.


Plus, since we want a single event case to handle all those indicator refnums, we would have to reregister all refnums each time a new window is opened (as mentioned above). But that means if you registered events for a window, then closed it, then opened a different window...when you open the second window, the re-registration of events from the first will throw an error because its FP is no longer open.


Confusing, yes. Hope that gets the point across.


Our workaround is that we have a separate daemon instance dedicated to each window. Not ideal, but works for now. But there are other similar problems that have required more complicated workarounds. Would be best if the root cause were addressed.


Active Participant

You might be able to bundle a cluster of arrays of control refnums for your dynamic event terminal, in such a way that you won't have to re-register the events that didn't change. Depending on your specific application this might be viable or not. Just for that one point in your post.



CLA, CTA, CLED & LabVIEW Champion
AristosQueue (NI)
NI Employee (retired)

This situation is why you can use the FP.Open *method* (not the deprecated property) and pass "Hidden" as the status. That brings the FP into memory without showing it on the screen. If you open it hidden, you can do the event registration that you're seeking.

Active Participant

Thanks for the suggestion, AQ. I'll look into invoking the FP.Open method as "hidden" for those instances where this is a problem. It'll also be a good excuse to clean up anywhere that we are still using the deprecated FP.Open property...

Proven Zealot

The problem with hiding the panel is that it fails when the panel is open in a sub panel.


It can be very tricky to register events when the panel can run in a subpanel or on it's own. IIRC, a hidden panel can't be put in a sub panel, if it's in a sub panel it can't be hidden, if it's not open you can't register. The panel itself might not know if it's in a sub panel or not. That combination is difficult, although I usually manage to get it working.


The static events work just fine when the panel is closed. I'm sure there are technical reasons why dynamic registration fails. But it's a simple thing even newbies will want to do, and it shouldn't be this hard.