Thanks to all (especially blawson) for the examples. I stand corrected--it is indeed possible. When I was playing around with passing a button reference through the front panel terminal before posting yesterday I wasn't getting events based on the calling vi's control, only in response to events on the reference number control on the sub vi. I don't have the sample I was playing with so I can't compare it with blawson's code to see what's different. (I do specifically remember changing my sub vi's control reference input terminal to strictly typed broke the calling code, even though to the best of my recollection the code was otherwise identical.)
I see blawson's example passes an Event Reg Refnum to the sub vi. To be honest I had completely forgot about that. (And this is after building a drop-in reusable event manager library last year!) I actually have done that before but found it to generally be more trouble than it's worth during development due to the hassle of changing them. Putting event reg refnums on the connector pane hinders flexibility even more than putting enums on the connector pane does. You can't change any of the events or add new events without breaking code all over the place. That's okay if you have all the dependent vi's in memory when you change it, but you may be in for a nasty surprise if they are not.
So yep, I was wrong about a sub-vi triggering on a parent's front panel events. However, looking at the example I was doubtful that a queue-based implementation would be more complicated than an implementation that requires a user event refnum, a control refnum, and an event reg refnum, so I refactored the example and posted it below. It has the exact same functionality as the original code with the a couple exceptions:
1. The top level vi doesn't continue receiving the sub vi's MouseEnter and MouseExit events after it has stopped. (That strikes me as really weird behavior... has anyone used that feature in a customer's application?)
2. The sub vi doesn't close itself--it sends a message to the calling vi asking if it can close. If the calling vi says it's okay, then it sends a message back to the sub vi telling it to close. I like to use this messaging pattern in parallel code modules that are designed for one caller at a time as it allows more flexibility (and therefore reusability) in how the module can be used. I included it here for kicks and grins.
Whether or not it's more complicated depends on what you're used to I guess. To me the queue implementation is more easily understood. I believe it is--without question--a more flexible solution than passing fp control refs or fp event reg refnums. Messages can come from any source, not just front panel events. They can also carry with them any data, not just the data associated with that particular event. The flexibility of being able to easily send what information I want, when I want to send it, is extremely valuable.
I also believe messaging with queues is a more scalable solution. Code that starts out in a parallel loop on the same block diagram can very easily be converted to a sub vi as more functionality is added. Later you can make it into a class or an actor object. Through all of those changes and added functionality the data type to communicate with that bit of code hasn't changed. It's still a queue for a message that has a name and data. (I confess I don't use string/variant messages anymore. I use an object-based messaging library that provides better type safety than the string/variant and includes error handling.)
Ben wrote:
Your thoughts are highly valued so plese "let er fly"!
Aww... now you're just trying to sweet talk me... 😉
When I'm developing an application I try to be very careful about managing dependencies between code modules and monitoring how complete each of those modules are. Stable modules (those that are finished) should never depend on unstable modules (those that have uncertain requirements.) If I have a stable module that depends on an unstable module then I run a high risk of having to change the code in my stable module when the unstable module's requirements change. In the worst cases all the prior work I've done developing and testing the stable module is wasted.
User interfaces are the most volitile aspect of the applications I develop. Users ask for all sorts of changes late in the project. Passing UI control references to the sub vis makes the application's functional code, which should be stablized, dependent on the UI, which is likely to change. When that happens changes to the UI often have a trickle down effect all the way into the lowest level sub vis.
I got tired of fighting that battle, so now user interfaces are the last thing I create. The UI is usually a thin wrapper that converts front panel actions into messages for the functional code and messages from the functional code into actions on the front panel. (Very similar to what is shown in "Top level - Queue.vi.") As an added bonus it is much easier to test functional code when it isn't dependent on a user interface.
Ben wrote:
I find this easier to code develop and teach to my customers (since they are the ones who will have to maintan it).
Thankfully this isn't one of my requirements. Flexibility requires abstraction, and if your customers will have a difficult time maintaining the code because it has more abstraction than they are used to, then you probably ought to use an architecture they will understand even if it compromises your/their ability to easily make changes in the future.
I'm not claiming using messages (via queue or user events) to communicate between parallel threads is always the right decision; that depends on the project requirements. I am claiming if modularity, flexibility, and scalability are your goals, messages are the way to go. Everything else is a compromise. My philosophy is to maintain as much flexibility as long as possible given the project contraints. Decoupling code modules and using messages to communicate go a long ways towards achieving that goal.
