User events unregister after a failed dynamic controls registration

[raphschru]

I think I found another bug with the Reg Events node:

When I use the Reg Events node to dynamically register both controls and user events (configuration shown below), a failed registration to the controls (i.e. because the FP is not open) also causes the user events to unregister. So I cannot use the user events to reliably stop the loop in case of error (The VI shown below is a dynamic VI controlled by a master VI that sends him requests using user events):

However in the NI example named "Dynamic Event Registration", it says "Unwired events on the Register for Events function are left unchanged.", so I assume it should be the true even in case of error...

To narrow down the bug even further, it seems these 2 slightly different configurations work as expected: after the value change registration gives an error, the user events are still registered:

Ironically I stumbled upon this bug by trying to find a workaround to another Reg Events node bug: https://forums.ni.com/t5/LabVIEW/Event-structure-updates-poorly-when-changing-events-connected-to/td...

Is this an expected behaviour ? Because these bugs tend to make the user events more difficult to use.

Find my example attached showing this behaviour with the 3 different configurations:

[wiebe@CARYA]

---

@raphschru wrote:

Is this an expected behaviour ? Because these bugs tend to make the user events more difficult to use.

---

This is to be expected. Well, I expect it, as I ran into problems with this before 😑.

And it is hard to express how much of a pain this is...

This (the entire 'fail registration when panel is closed') would in fact be my nr 1# priority to fix, although it seems to be ignored completely by NI.

I guess leaving unmodified events unchanged even if they are in a cluster is a complementary bug though.

---

@raphschru wrote:

However in the NI example named "Dynamic Event Registration", it says "Unwired events on the Register for Events function are left unchanged.", so I assume it should be the true even in case of error...

---

Sadly, the bug fix might be to change that example. The event registration's help doesn't mention this at all.