Event Structure frames can incorrectly remap to other dynamic events

[Jim Kring]

[CAR 148149]

Background

There is a bug in the Event Structure where code in frames of an Event Structure can get re-associated with a different/wrong Dynamic Event when the input event reference data of a Register For Events node changes.

Short Video Demonstration of the Bug

And, here's an example VI that you can use to test it for yourself:

Download File:post-17-1235239395.vi

Steps to Reproduce

• Open "Dynamic Events Bug.vi"
• Cycle through the Event Structure frames
  • Note the contents of the frames for Event A, Event C, and Event D.
  • Note the cluster constant with user event reference constants for Event A, Event B, Event C, and Event D

  [*]Delete the Event B user event constant from the cluster constant.

Observed Results

• Cycle through the Event Structure frames
  • Note that contents of the Event Structure frames for Event C and Event D got swapped: the contents for Event C are now associated with Event D.

Expected Results

• The contents of the Event Structure frames for Event C and Event D should remain unchanged (they should not be swapped)

[Val Brown]

QUOTE (Jim Kring @ Feb 21 2009, 11:11 AM)

Background

There is a bug in the Event Structure where code in frames of an Event Structure can get re-associated with a different/wrong Dynamic Event when the input event reference data of a Register For Events node changes.

I haven't had the time to download and test this but I'm wondering if you know the behavior for 5 or 6 such events and deleting one: ie where do the remaining events map now? There may be an underlying logic to the actual behavior which, although it looks pretty clearly "buggy" to me, might allow us all to work with it until it is fixed. FWIW it sounds like a index reversal issue in the underlying code of LV itself and the event registration process.

[Grampa_of_Oliva_n_Eden]

QUOTE (Jim Kring @ Feb 21 2009, 01:11 PM)

• ...The contents of the Event Structure frames for Event C and Event D should remain unchanged (they should not be swapped)
  

Thank you very much for the heads up Jim! :thumbup:

I wonder if that is realated to ?CAR# 117209 ? where edits of a type def cluster could show an analogous effects. The suggested work-around was to edit the type def with the callers closed and only open them after the change. I worked up a duplicate of your code in LV 8.5 and duplicated the bug you demoed.

I converted it over to a type def version and achieved a similar effect by deleting an element from the type def hit apply changes, then did an un-do in the typed def and hit apply changes again.

I then backed-up and tried the edit of the typed def with the caller closed and it did not mix up the events.

So editing type def with callers closed may help you work-around/avoid this issue. Yes I am assuming you are using type defs in your real code.

Just trying to help,

Ben

[Omar Mussa]

I've been bit by this bug but wasn't sure how to reproduce it! The only 'workaround' I know of is to label each dynamic event frame (like you did in the video) so that whenever you add/remove events to the 'register for events' node you can validate that the events weren't remapped.

[shoneill]

QUOTE (Omar Mussa @ Feb 22 2009, 08:59 PM)

I've been bit by this bug but wasn't sure how to reproduce it! The only 'workaround' I know of is to label each dynamic event frame (like you did in the video) so that whenever you add/remove events to the 'register for events' node you can validate that the events weren't remapped.

I work a lot with user events and this kills me every time I change a typedef. It can get hairy sometimes trying to re-align the frames with the events on the dynamic terminals.

Labelling sounds like a pretty good idea.

Shane.

[Jim Kring]

QUOTE (neBulus @ Feb 22 2009, 07:17 AM)

Thank you very much for the heads up Jim! :thumbup:

I wonder if that is realated to ?CAR# 117209 ? where edits of a type def cluster could show an analogous effects. The suggested work-around was to edit the type def with the callers closed and only open them after the change. I worked up a duplicate of your code in LV 8.5 and duplicated the bug you demoed.

I converted it over to a type def version and achieved a similar effect by deleting an element from the type def hit apply changes, then did an un-do in the typed def and hit apply changes again.

I then backed-up and tried the edit of the typed def with the caller closed and it did not mix up the events.

So editing type def with callers closed may help you work-around/avoid this issue. Yes I am assuming you are using type defs in your real code.

Just trying to help,

Ben

Hi Ben,

Thanks for the information. This is very helpful.

The only problem that I see with the work-around you mentioned (editing type def with callers closed) is that I use classes a lot. And, having any member of a class (e.g., a type definition that is a member of a class) will cause all class members to be loaded into memory (e.g., VIs with Event Structures whose dynamic events use the type definitions).

Thanks,

-Jim

[Aristos Queue]

QUOTE (Jim Kring @ Feb 22 2009, 06:54 PM)

The only problem that I see with the work-around you mentioned (editing type def with callers closed) is that I use classes a lot. And, having any member of a class (e.g., a type definition that is a member of a class) will cause all class members to be loaded into memory (e.g., VIs with Event Structures whose dynamic events use the type definitions).

As a workaround to that, rename the class file, load the typedef, edit it, then rename the class back to its original name and open it. This shouldn't be necessary, but since you're working around the other bug, this workaround becomes useful.

[Grampa_of_Oliva_n_Eden]

QUOTE (Aristos Queue @ Feb 23 2009, 04:48 AM)

As a workaround to that, rename the class file, load the typedef, edit it, then rename the class back to its original name and open it. This shouldn't be necessary, but since you're working around the other bug, this workaround becomes useful.

[TongueInCheek = True ]

And I though the game of "Twister" was a part of history.

[TongueInCheek = False ]

Ben

[ned]

Aahh, the frustration. I never knew that Register for Events accepts a cluster of user event references (and I haven't seen it documented anywhere). Do I take advantage of this trick to clean up my code, or stay away from it to avoid this bug?

[Jim Kring]

QUOTE (Aristos Queue @ Feb 23 2009, 01:48 AM)

As a workaround to that, rename the class file, load the typedef, edit it, then rename the class back to its original name and open it. This shouldn't be necessary, but since you're working around the other bug, this workaround becomes useful.

An easier solution would be to

1. open and edit the typedef,
   
2. don't save any other changes,
   
3. close all VIs,
   
4. reopen the project, and then
   
5. save all changes.
   

QUOTE (ned @ Feb 23 2009, 07:25 AM)

Aahh, the frustration. I never knew that Register for Events accepts a cluster of user event references (and I haven't seen it documented anywhere). Do I take advantage of this trick to clean up my code, or stay away from it to avoid this bug?

Unfortunately, avoiding clusters won't help you avoid this bug.

Below, is another example using scalars and multiple event terminals on the Register for Events node

Short Video Demonstration of the Bug (using scalars instead of clusters)

And, here's an example VI that you can use to test it for yourself:

Download File:post-17-1235412403.vi

Steps to Reproduce

• Open "Dynamic Events Bug (scalars).vi"
  
• Cycle through the Event Structure frames
  • Note the contents of the frames for Event A, Event C, and Event D.
    
  • Note the cluster constant with user event reference constants for Event A, Event B, Event C, and Event D
    

  [*]Delete the Event B user event constant.

  [*]Right-click on the second User Event terminal on the Register for Events node and choose Remove Element.

Observed Results

• Cycle through the Event Structure frames
  • Note that contents of the Event Structure frames for Event C and Event D got swapped: the contents for Event C are now associated with Event D.
    

Expected Results

• The contents of the Event Structure frames for Event C and Event D should remain unchanged (they should not be swapped)
  

[Jim Kring]

Update: CAR 148149 assigned by NI.

[LAVA 1.0 Content]

Is this an edit time or run time bug?

Ton

[Jim Kring]

QUOTE (Ton @ Feb 25 2009, 10:19 AM)

Is this an edit time or run time bug?

Ton

It is an edit time bug in LabVIEW that creates a run time bug in your application.

[wildcatherder]

I'm still seeing this bug at the end of the year 2012 in LabVIEW 2012. I do not understand the workaround. I am using clusters as inputs. There are no "callers", as this is in the top-level VI.

Has nothing been done about this bug?

Is there any way to remove an unneeded User Event?

Is there any harm in just leaving it in place, unused?