OOP Event Changes between 2009 & 2010

[Francois Normandin]

Something fundamental seems to have changed between LV2009 & 2010 about Events Refnums and OOP.

This arises from investigating why my code breaks down in LV2010 (LVOOP Event Handler in code repository).

In LV2009, it used to be possible to make an array of events where the event refnum of child classes could be carried on the wire of the parent class event refnum.

This has changed in LV2010 as it is no longer possible.

Digging a little on this issue, I found out that the "equals" primitive has also changed behavior between versions.

It seems that if the datatypes can be arrayed, it should also be allowed to compare them, right?. Granted, it should still return "false" if the refnums are not pointing to the same objects, but why the broken wire in 2009? This behavior has been corrected in 2010 so it seems that LV recognized that these are of the same type (or at least in a parent/child perspective). So why would it be impossible to make an array to these?

At least, we can still pass a child object on the parent event refnum... and not a parent object on a child event refnum (consistent).

Anyone can confirm that this is a bug and not expected behavior? And obviously, one version has a bug... which one? Both?

[Aristos Queue]

The wire that is now broken is correctly broken.

The wire that is now fixed should still be broken, but at least that one won't crash LV, whereas the other one will.

You should never be allowed to cast an event of child as an event of parent. Consider a hierarchy of Parent, which has two children named Son and Daughter. I create an event of Daughter. I register it with an Event Structure, which now has a Daughter type output. Then I cast the event refnum as an event of Parent. Then I use Send Event to fire the event, but the data I give it is of type Son. The son data is transmitted and comes out of a Daughter terminal in the Event structure. This is a problem because the private data of Son will be incorrectly interpreted, and you may crash. Yes, this metaphor leads to some terrible jokes. But the crash that occurs is no joking mater.

I do not know why the Equals prim is allowing the comparison, but at least that comparison isn't actually trying to interpret the data, and it will always return False, since we've blocked the casting.

Now, having said all that, there's a back door to casting that I cannot ever close. Use the following at your own risk: If you have an event of Daughter, you can use the Type Cast node to cast it as an Int32. Then you can use a second Type Cast node to cast that Int32 as an event of Parent. You now face the same danger of crash that was there before. Your framework had better guarantee that the event of Parent is buried so that no one can transmit arbitrary data to that event.

I'll file a CAR about the Equals operation. Don't write code that relies on that comparison being legal -- it's going to close again now that I know about it.

[LATER] CAR 294872 filed.

[Francois Normandin]

You should never be allowed to cast an event of child as an event of parent. Consider a hierarchy of Parent, which has two children named Son and Daughter. I create an event of Daughter. I register it with an Event Structure, which now has a Daughter type output. Then I cast the event refnum as an event of Parent. Then I use Send Event to fire the event, but the data I give it is of type Son. The son data is transmitted and comes out of a Daughter terminal in the Event structure. This is a problem because the private data of Son will be incorrectly interpreted, and you may crash. Yes, this metaphor leads to some terrible jokes. But the crash that occurs is no joking mater.

The reasoning makes sense to me now. Thanks for clearing that out.

I put up an example which I think shows how I used it (safely) and how it can be used as you describe and crash LabVIEW. Basically, if I index the array of event refnums, I'll always propagate the data as a "Parent" and never encounter the situation above. However, if I fork the child event and use the arrayed one to transmit the data, then I can cause LabVIEW to stop.

Obviously, I'll have to find another way do achieve what I want. The potential is too great for the work-around you've suggested to be implemented in shared code.

Test Event 2009.vi

[Aristos Queue]

I cannot reproduce the good wire on the Equals prim in LV 2010. Here's what I get:

Do you see anything that I have different from what you were doing? I tried adding the other nodes on the wires (such as the Send Event node) and that didn't make a difference.

And in the VI you just sent, can you just use parent events and send the appropriate data later?

[Francois Normandin]

I cannot reproduce the good wire on the Equals prim in LV 2010.

Do you see anything that I have different from what you were doing?

I bet that you have SP1 installed... I haven't. Before tackling this issue with a piece of code in CR, I had not used LV2010 since last NI Week. So I guess you guys corrected the bug with the 2010SP1 release.

And in the VI you just sent, can you just use parent events and send the appropriate data later?

I would normally, but this is part of a framework that the user must simply feed the class type and the rest is done automatically. So in an ideal world, what you propose is pretty much the right thing to do to make sure my paradigm doesn't crash LabVIEW, but here I can't because the user can fork create his own events in parallel, and he might receive the events I send with my framework.

I'm refactoring the whole framework. Hopefully it will be even better because I will also circumvent the "bug" misunderstood by-products of an intended by-design behavior of events that cursed Justin at the CLA Summit, which I just read about after listening to Mickael's podcast...

[Aristos Queue]

I bet that you have SP1 installed... I haven't. Before tackling this issue with a piece of code in CR, I had not used LV2010 since last NI Week. So I guess you guys corrected the bug with the 2010SP1 release.

I forgot to check LV 2010 before the SP1 patch. Well, I'm sorry it broke, but I'm glad we fixed it.

[Francois Normandin]

I forgot to check LV 2010 before the SP1 patch. Well, I'm sorry it broke, but I'm glad we fixed it.

You guys are more efficient than you think .