Event structure spontaneous disconnection from FP control

[adam.hopkins]

I came across an issue in an application I am maintaining where an event structure appears to have spontaneously disconnected from the FP control it is listening to. I have a timeout event every 200ms and when I click the FP control it generates an event that is marked (unhandled) in the event log:

27259 10 33346325 00000000 Timeout - 
27260 10 33346525 00000000 Timeout - 
27261 10 33346679 C7B00024 Value Change (unhandled) "FF" 
27262 10 33346725 00000000 Timeout - 
27263 10 33346909 C7B00024 Value Change (unhandled) "FF" 
27264 10 33346926 00000000 Timeout - 
27265 10 33347127 00000000 Timeout - 
27266 10 33347328 00000000 Timeout - 
27267 10 33347347 C7B00024 Value Change (unhandled) "FF" 
27268 10 33347529 00000000 Timeout - 
27269 10 33347729 00000000 Timeout - 
27270 10 33347782 C7B00024 Value Change (unhandled) "FF" 
27271 10 33347929 00000000 Timeout - 
27272 10 33348129 00000000 Timeout - 

 When opening the events handled by that case, I can see that the event source is not selected: 

The error goes away once the event source is selected. Any idea what could have caused something like this to happen and how to prevent it in the future? And if not how to prevent it, how to at least design a test for it?

[billko]

I guess I'm not following you.  Are you saying that if you change the timeout to handle the FF event, then the event starts being handled?  Seems normal to me, if that is the case.

Or do you mean that you originally had a case for FF value change and then somehow the case for FF value change showed that it was no longer handling the value change?

[adam.hopkins]

---

@billko wrote:

Or do you mean that you originally had a case for FF value change and then somehow the case for FF value change showed that it was no longer handling the value change?

---

This. I had an event structure that had a case for FF value change already. The event log shows that the event happens, but is unhandled even though there is code in that event case. 

For some additional context, we're managing revision control through git, and I identified the commit that introduced the issue. It looks like there were not any changes to the cases in the event structure (apart from the previous screenshot where the event source is not highlighted in the "Edit events handled by this case" dialog).

The only thing I can think of that may have caused this is if the VI merge tool was used. I have used VI merge to help with highlighting the differences, but I then go back and make any changes manually rather than relying on the merge tool to do the job. My concern is this bug was introduced in our software on a commit that did touch our top-level vi, but should not have touched the event structure. I'm trying to find 1) how this issue could have been introduced to prevent future similar issues from occurring and 2) how to test for/detect that an issue like this has occurred in the future.

[Jacobson]

Are there any dynamically registered events? I don't think I've ever seen an unhandled statically registered event before (not sure how it could even happen).

[adam.hopkins]

There is a dynamic terminal on the event structure, but no dynamic events registered to it.

[Kyle97330]

I have had this happen before under very specific circumstances.

The first condition is that it's a type-defined cluster as a control.  If it's not type-defined, this doesn't happen.

The second condition is that the event is added programmatically.  If I add it manually, or using the right click Create -> Event -> Value Change option, no problem.  This is the code I use:

If I meet both of those conditions, then I get an event setup like you got, where you should have a value change event, but somehow the middle column doesn't have the <All Elements> selection made, so it doesn't actually work.

I never raised this as a bug because it was something I only do very rarely and there's a simple enough workaround (manual selection of the middle column <All Events> option) in the rare cases when I do use it.

You may not have used this yourself, but it's possible something in "merge" ran this or the code equivalent when changing your VI and triggered the same effect.