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.
