Rif.: Get the control references from Dynamic Event Registration refnum

[1984]

Hi,

I'm passing a Dynamic Event Registration refnum from my main VI to one of my subVIs, so it can process some of the button presses on the FP of my main VI.

The problem I'm facing is that must have the refnum of the controls as well in my subVI before I start using them in an Event Structure.

If I hover over the wire to the event registration refnum then I see which button is "inside" the wire, so I guess the references could be extracted. Or am I misusing the event registration refnum, and I really should wire the control references into the subVI and register for events there?

thanks.

[pincpanter]

Pass all the references you need to the subvi and register the events therein. You cannot extract control references from events registration refnums.

[1984]

Its quite strange though, because the event refnum certainly contains the refnums in some form as the event structure in the subVI can extract them. Passing the refnum to the subVI just makes thing a bit more complicated as now I have to create a typedef'ed cluster of the references pass it to the subVI, unbundle it and register for the events there.

Maybe there is a good reason for that which I just dont get, but for the first it looks odd.

[pincpanter]

References are someway hidden into the refnum but AFAIK there is no way to extract them (unless there is some undocumented vi which in any case I would prefer not to use).

If you need to manage the same event types for all controls (say Value Change) you don't need to unbundle, though. Simply wire the cluster to the Event registration node. You may also group the controls depending on the event types.

[wiebe@CARYA · Accepted solution]

We've been through this discussion before.

There's even an idea exchange idea for it, and also one actually limiting what we do have.

It's in general a bad idea (what I get from the discussion, not my PoV per se), because the event registration might encapsulate references that are supposed to stay private. If for instance a class returns a registration, it's encapsulated data should stay encapsulated. If you could get the references from it, it would encourage bad practices.

I'd simply pass the control references, and register them in the VI. Or put the control references in a class, let the class do the registration, and get the registration from the class if needed. The class can in some cases handle the events itself, similar to Q Controls.

[wiebe@CARYA]

---

@1984 wrote:

Its quite strange though, because the event refnum certainly contains the refnums in some form as the event structure in the subVI can extract them. Passing the refnum to the subVI just makes thing a bit more complicated as now I have to create a typedef'ed cluster of the references pass it to the subVI, unbundle it and register for the events there.

---

The reference doesn't contain this information.

The reference refers to this information. The LV IDE can access this information, and we can't (unless maybe if we try real hard).

[1984]

Alrighty! Thanks for your thoughts, I will pass my refs in a cluster.

[wiebe@CARYA]

---

@1984 wrote:

Alrighty! Thanks for your thoughts, I will pass my refs in a cluster.

---

Try an array if you can. If the types are the same, or you don't need the specific types (they're all Control types), an array is less maintenance.

Both an array and a cluster feed straight into the event registration.

[1984]

I've tried, but then in the SubVI when I set up the event strucutre the event structure doesnt show clearly which action belongs to which button. Plus if for whatever reasons the order of the array changes in the main VI I have to reorder the events in the subVI as well, which is a pain in the back and very error prone.

I ended up using a typedef'd cluster, thats probably the cleanest solution.

[wiebe@CARYA]

---

@1984 wrote:

I've tried, but then in the SubVI when I set up the event strucutre the event structure doesnt show clearly which action belongs to which button. Plus if for whatever reasons the order of the array changes in the main VI I have to reorder the events in the subVI as well, which is a pain in the back and very error prone.

I ended up using a typedef'd cluster, thats probably the cleanest solution.

---

It depends.

Not sure what you want to do.

I'd put the refs in a class, as mentioned. I never have to use type defs anymore (of course a class is somewhat of a type def).

If it's just the on input of the VI, I probably wouldn't make a type def at all. Just a cluster. If it changes, the wire breaks, and it's clear and unambiguous what needs to be fixed. The type def isn't bad, perhaps even good, but to me one more dangling file.