Get list of event structure dynamic events

[Ben]

---

@awilliotAcutronic wrote:

@Darin.K

That would be nice, but unfortunately the refnum TDs do not seem to be documented. I guess the Event Registration Refnum has its own TD implementation.

@Ben

- I have issues with the events being shifted when I add or remove events from the SubVI, I guess you refer to that problem. But I still prefer to keep the SubVI.

...

---

---

It is a matter of taste, red pill or blue pill.

I would argue that pushing the registration into a sub-VI obfuscates the code making a "reader" poke into a sub-VI rather than making obvious which event THIS VI handles.

BUt nobody here can say one way is right and another is wrong.

Have fun!

Ben

[Ben]

Another thought that may further this discussion is based on an old Nugget where I explained how to use a "bundle" (not a bundle by name) to create a cluster that matches what is wired to it.

Discalimer: The web-site stripped the images long ago so close your eyes and imagine what I was trying to say.

In this case if you right-click the middle input of the bundle where you are bundling your event registration wires, and crate a constant, LV will generate the constant for you. From there scripting can get at the components of that cluster and get the events you are seeking?

I post this idea not as a solution but in the hopes that it does inspire a real solution. There are admitedly problems that need to be worked out.

Ben

[wiebe@CARYA]

Registering in a subVI (class method) can be a good thing. I do it all the time.

If not registering inside the method, the user event needs to be exposed. That means everyone can start sending that user event. Exposing the registered event allows users to register for the events, but without the possibility of users messing up by exposing the event itself.

Anyway, this has all been discussed before...

[Intaris]

With regard to the type specifier, I used to do a lot of parsing of those back in LV 6.1 days.  I'm a bit rusty now but here's what occurred to me off the bat:

I'm unsure of some of the fields (some appear static - that is they don't change if the number and types of Events contained within change) Others do.  The Descriptors are always hierarchical, with length descriptors throughout. This is by no means a solid reference to go by (I used to know the Object Types off by hand: Here's an old link) but it might be enough to judge whether it's worth your time or not.

[wiebe@CARYA]

Isn't the some OpenG, MGI, or whatever library for doing that?

[Intaris]

Most likely there is

[Ben]

If we crate that cluster that I mentioned in my previous post...

Will the

Varaint >>> Data Type Parsing

functions tell us anything?

That palette has been added since I last was interested in discovering data structures so I have not used them much but seem to fill the gap what the MGI tools filled.

Just sharing ideas,

Ben

[mcduff]

It looks like this topic is cross-posted on LAVA and there is a link to an elegant solution.

https://lavag.org/topic/21003-how-to-get-list-of-events-from-an-event-registration-refnum-as-variant...

mcduff

[Darin.K]

When I pointed towards this rabbit hole I was only considering User Events, those names are indeed pretty easily grabbed from the type descriptor.  The image posted after my first reply changes things, a lot.  Lets pretend you use your favorite method to get the names, pretty quick work with the built-in variant data library.  

1)  Those names are useless when it comes to scripting the event structure.  There you need the index in the register function, not the name.  What you need to do is grab the number of elements from the type descriptor, and then use scripting to determine which ones are already handled, and then add frames for the rest.

2)  For non-user events (from controls/panes/etc) the name you get is that of the object, not the event.  The event type is encoded in the 4 bytes before the name.  I have a decent, but probably incomplete mapping, but this is not provided in the cross-posted solution nor by the built-in variant functions.  If you have 3 events registered from a control, you will see the control name three times in the list.

What I would try is to create a new VI with an event structure and a constant event registration refnum created from the current event structure dynamic terminal.  I have attached a very quick and dirty proof of principle.  Scripting Event Structures is a buggy mess, that is why I did not add a new frame for each user event, adding a second user event errors out.  Non-user events are fine.