03-10-2016 12:09 PM
I'm trying to register multiple events for use in a subVI to handle user input for my application. I've read up a bunch on dynamic event registration. I know it is possible to place the refnums into a cluster for use with the 'event source' terminal of 'Register For Events'. I was wondering if it was possible to use an array of refnums instead. That way I don't have to edit the front panel and terminals of my subVI every time I decide to pass it an additional refnum / event.
Currently if I wire in an array of refnums to 'Register For Events' I end up with only one entry under 'Dynamic' event sources (whereas if I use a cluster, there will be many). Is this because LabVIEW won't know what the array contains until runtime and therefore it wouldn't be possible to know before runtime what event sources exist?
Thanks in advance for any thoughts / opinions / musings on this.
03-10-2016 12:15 PM
I haven't tried this but I would be very surprised if it worked. The problem is that an array has to be an array of exactly the same things, and while the items in questions are all event registrations, they are (at least potentially) all different with different data, etc...
Mike...
03-10-2016 12:20 PM
With an array of renums, it treats it all like a single control. Think of it like when you statically create an event case for multiple buttons. It has to do this since 1) all of the reference types must be the same and 2) it is unknown how many renums will be passed in the array. With clusters, everything is fully defined.
03-10-2016 12:27 PM
@regenerator wrote:
Currently if I wire in an array of refnums to 'Register For Events' I end up with only one entry under 'Dynamic' event sources (whereas if I use a cluster, there will be many). Is this because LabVIEW won't know what the array contains until runtime and therefore it wouldn't be possible to know before runtime what event sources exist?
Yes.
The obvious thing is to also just try running it and seeing how it behaves. You should find that it does work and that the single event case does handle the events from all of the controls referenced in the array.
If you want to have multiple strictly type cases but not to edit things all the time, you can make the cluster of references a typedef (which you should generally do with clusters used in more than one place anyway). That way you just add the reference to the new control to the typedef and it's updated everywhere. You will have the code than bundles the cluster and the code for handling the event, but you would have to do that anyway.
03-10-2016 02:00 PM
Thanks for the responses. I hadn't thought about using type defs to make the subVI wiring more straightforward.
It makes sense that you can't pass an array of refnums to 'Register For Events' and then configure more than one event case because you can't know how many elements will be in the array at runtime.
However, I gave it a shot and wired up a simple example:
There is only one dynamic event case that can be configured, but changing either boolean results in an event occurring and the 'CtrlRef' corresponds to the changed control. I guess another way to think about it would be that wiring an array of refnums will cause an event to be generated if any of the refnums undergo a Value Change. This is basically what crossrulz said above (thanks :)). What I was unsure about was what exactly 'CtlRef' would point to, or if you'd be able to determine which refnum the value change occurred in.
Does anyone know if this behavior is documented somewhere? It seems like event registration is a bit lacking in terms of official documentation.
03-10-2016 02:07 PM
03-10-2016 03:01 PM
You can also use arrays of references of different types; booleans and strings and numerics, etc. The OldVal and NewVal will switch to Variant. As an added advantage, the data in the Variant will be named the same as the control, so you can get the name via "Get Type Information.vi" which is much quicker than a property node.
03-10-2016 03:22 PM
I'm currently using an array of refnums to different types, also dealing with variants. I didn't know about the 'Get Type Information.vi' trick though to extract the name. Thanks!
03-11-2016 10:10 AM
The Get Type Ino is relatively new.
IN the interest of ease of support I will use the cluster approach. This makes it easy to see "at a glance" which events aaare registered by the sub-VI and then locate the event case that handles that event.
Just my 2 cents,
Ben