Event structure updates poorly when changing events connected to the "Reg Events" node

[raphschru]

It seems the event structure maps dynamic events from the Event Registration Refnum using their position in the "Reg Events" node.

So when you add a new event before an already implemented one, you can get weird updates of the event frames...

Here is an example where an existing event is incorrectly replaced by a newly created event:

Another example where an UI event on multiple controls is completely lost after a change to the node:

To me the event structure should be smarter to map dynamic events to frames:

1. Either by multiple criterias:

- First by the name of the user event / control(s) constant;

- Then only if several events have the same name, use the index in the "Reg Events" node.

2. Or only by name and forbid registering several events with the same name.
Then the user may have to use the "Coerce to Type" function to rename controls arrays or clusters to give them a unique name.

[billko]

I tried example #2 in LV 2018 SP1 and it seems to work correctly.

[raphschru]

It's in LabVIEW 2020 SP1.

Here are the VIs to reproduce the problem.

For example #2 be sure to release the mouse after each resize to prevent LV from simply undoing the last move.

[billko]

Sorry, I just posted that data point just so we can maybe pinpoint when it started happening, not because I didn't believe you. 🙂

[Yamaeda]

I'd assume user events are registered by the index#, so when you expand upwards, you get a new #1. Similar to how Enums can reacts. It should ofc try to keep it's named registration first hand.

[raphschru]

I also tested with LV2016 and LV2018 and it behaves exactly as I showed for LV2020.

So the "bug" was always there.

You can test with LV2018:

[crossrulz]

I'm seeing the same issues with 2019SP1 and 2021SP1.

At least with the control register one, it really looks like it is an indexing issue, like it is adding 2 or 3 to the index when you expand up.  Notice that the "Unknown Event" is labeled as index 3 instead of what should be 0 or 1. If I had to take a wild guess, I would say the index is being added by the Register For Events and then again by the Event Structure trying to keep the event index synchronized.

[billko]

---

@raphschru wrote:

I also tested with LV2016 and LV2018 and it behaves exactly as I showed for LV2020.

So the "bug" was always there.

You can test with LV2018:

---

Thank you for your patience.  I rebuilt your code incorrectly and now I can say I can see the described behavior as well.

[billko]

I've never added a user event to the top like that before, but I have made room for one in the middle.  I wonder if we see similar issues and I just got lucky and because they were the same data type and I didn't write code for the events yet, so it didn't matter?

[raphschru]

With the controls array, my own guess is that the frame is initialliy linked to event #1.

After adding an element at the top, new event #1 is incompatible with the currently linked frame, so it goes to (nbr_of_events+1), so 3 in this case.

Then even when you remove the element you just added, the link is broken and stays #3.

You can test with e.g 5 user events, the frame will turn into #6.