.net Event Delegate being reset to null

[ChrisBonnar]

I have the attached code in a C#.NET DLL. Labview listens to the EventHappened event and receives an integer (EventID) when my DLL raises the event like so:

          EventID = 2.

Basically, the DLL raises numerous events throughout the lifecycle, starting with ID 1 (Waiting), ID 2 (Connected) and ID 3 (Initialised). The DLL interfaces to a web application and in the process it waits, connects and initialises - passing back these events to labview for action.

Events 1 and 2 fire correctly, but for some reason by the time it comes to 3 (which could be a few seconds later), the _EventHappened object is null. You can see in the code that when the EventID property is set, a check is done to see if the _EventHappened object is null. If it is not null, it goes ahead and raises the event:

          this._EventHappened(this.m_EventID);

By the time it comes to event 3, the check occurs and the event IS null, and so doesn't try to call the event. I have no idea what is making this _EventHappened object disappear. It is extremely annoying!

I know this is a long shot since handing you a screenshot and a bunch of code isn't likely to get results - but can anyone shed any light?

Please see my attachments.

Thanks!

[nathand]

Is there any possibility that your LabVIEW code stops running before Event 3 occurs? There's something odd going on with the while loop Stop condition - looks like maybe there's some other node hidden under the stop condition, and there's no need for the wire running to the edge of the loop - that makes me wonder if maybe you're accidentally stopping the while loop after Event 2 occurs, so it unregisters for events and never catches Event 3.

[ChrisBonnar]

The event handler and loop is just a variation on the example you gave me in my previous post:

http://forums.ni.com/t5/LabVIEW/Returning-data-from-a-Reg-Event-Callback-to-the-calling-VI/m-p/30758...

The event handler takes care of two events: receiving the integer (this was a string in the example) and also acting on the stop button becoming true - this is the connection to the outside of the loop you mentioned.

Placing a breakpoint in my DLL using Visual Studio, I can see that the actual unregistering of the event only happens when I abort the LabVIEW program, not any earlier...

[Eric.M]

Does Event 3 use the same instance of vAutomation as Event 1 & 2 (or can you make sure the instance is not destroyed ) ? If it's not, do you make sure the event is properly registered to the delegate ?

Does calling vAutomation in another C# namespace (in Visual Studio) change anything compared to LV ?

Just a few thoughts 🙂

[ChrisBonnar]

Event 3 does use the same instance of vAutomation. I have written a sample windows forms app in C# which does not reproduce the same behaviour as LabVIEW.

The C# app recieves events 1 & 2 and waits around for event 3. Infact, I can raise event 3 from my website mutliple times and the C# app receives the event several times.

Any other thoughts?

[ChrisBonnar]

I have observed that after shutting down LV and relaunching the project, the program functions as expected/required - first time only. When re-run, it is a hit or a miss whether event 3 will fire or not. This is leading me to think that something isn't being closed or unregistered properly. Something that is remedied by restarting LV...

After pressing the stop button on my front panel, the loop exits and the register/close nodes operate, followed by application stop. Please see the far right-hand side of the attached diagram. I have verified this by running in Highlight Execution mode

Can anyone see anything I am missing? Something not being closed or unregistered?

[nathand · Accepted solution]

The "STOP" in your sequence structure is completely unnecessary, and might be part of the problem. It's equivalent to hitting the STOP button in the toolbar, which aborts a VI without necessarily closing everything normally. Your code will stop running when everything finished executing anyway, and by the time reaches that STOP it everything else should have finished anyway (but there could still be some cleanup in progress).

I also recommend that you chain the error wires for Unregister for Events, Destroy User Event, and .NET Close. Chaining the error wires will let you guarantee the order in which they execute, and then you can put an indicator on the output in the unlikely event that there's an error that occurs during cleanup (in which case, the error text might help explain the problem). Make sure those nodes execute in the opposite order from creation; I would first unregister for events, then destroy the user events, and finally release the .NET refnum. It's possible that if those actions are occuring in a different order, it would prevent something from being closed or unregistered properly (for example I'm not sure what happens if you try to unregister for events on a .NET object that's already been released).

[ChrisBonnar]

Thanks Nathan, that was the problem. I guess things werent being closed in the correct order.

As it happens, there was a little niggle in my DLL too, but its all working now!