With dynamic events, I was wondering if there was a way to have controls with multiple functions. A good example would be a START button that would change into a STOP button. It would be great to have one event case per funtion and determine dynamically which case will execute for the specified button press. I was thinking that you would have to register the control for each individual function you wanted. Then the question arrises, how do you switch registration over to another event case. Any suggestions?

Here is an example that does this. However, it appears that there is a LabVIEW bug that is causing problems with the reregistration. :?

Wow, I came up with the same thing... and got the same bug as well.

I downloaded your two demo files (one for latched boolean and one for switched boolean) and played with them until they worked. I think the original problem may have been too many events registered.
("If you do not unregister for events, LabVIEW continues to generate and queue the events as long as the VI runs, even if no Event structure is waiting to handle them, which consumes memory and can hang the VI if you enable front panel locking for the events.")

Since the terminal of a latched boolean is supposed to be read in its Value Change event case (ref events caveats and recommendations documentation) and you can't use local variables for the latched boolean, I created a user-event case where the terminal can be read. Not sure why just changing it to a switched boolean doesn't work, but this causes a "class conflict" error. (explanation anyone?)

Jon Sweeney

Since my previous post, I have belatedly read the documentation for "Modifying Registration Dynamically" and have a better understanding of what you were trying to do with the "Not a Reference"s (ie, using them to unregister events) . My modified interpretation of why the vi hangs follows:

Assuming the event registration structure is interpretted top-down like a property node is, in one eventcase (the 1st one encountered) you are unregistering and then registering the value-change event (net result=the event is registered). In the second eventcase (which causes the vi to hang) you are registering the event and then unregistering it (net result=the event is unregistered).

If this interpretation is correct, I'm not sure if you can call the behavior a bug or expected-but-unwanted.