Showing results for 
Search instead for 
Did you mean: 

.net event callback VIs - Why do they never leave running state?

Go to solution

I've been working with a bunch of event callbacks from the .net datagrid in my open source DataGrid project and while I have all the events I want to use working fine with callbacks, there seems to be no way to get a callback VI out of the running state, even after unregistering the events and closing the VI.  Even the NI example VIs have this problem.  It always leaves the VIs in a running state.


The reason this is a problem, is because when I'm developing the .net grid control and testing the interface, every time I run the application and close it, it leaves my main library then in a locked state becuse there are running VIs in it.  This forces me to have to close the project and reopen to kill those VIs.  There is no way to abort them with VI server either as they are "Not in a compatible state for this operation".  VERY frustration.


Is there any way around this so that the VIs that are used as callback Vis don't get hung up in a running state?  Why is this?

0 Kudos
Message 1 of 31
I don't understand what you mean: "no way to get a callback VI out of the running state". Callback VIs don't run in the normal LabVIEW execution environment.


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 2 of 31

If you attach a callback VI using the register callback, the VI execution state becomes 'running' and so anylibrary or class using that VI is then locked for editing.  You can see this in the examples shipped with LabVIEW even.  Despite UNREGISTERING a callback event, the VI execution state stays running (whether its in another execution environment or not) so you can't edit those locked class/libraries.

0 Kudos
Message 3 of 31
Accepted by topic author Mike_King

Hi Mike,


I was able to find a document that provided a potential work-around for the issue you are describing:


.NET Callback Event VI keeps the Callback VI reserved even after calling a Close Reference VI is called
For example, when running the "Passing data to a .NET Event" example, after stopping the main example VI, the "Callback -" is still reserved.

Workaround: I've come up with a work around for this problem. GC.Collect() can be called manually from the invoke node in a separate VI(Or the user could call it after un-registering the callback). This would un-reserve the callback VI. Steps : 1. Drop an invoke node in an empty VI 2. Right click on the node and in the menu under "Select Class" -> ".NET" choose Browse. 3. In the Class browser dialog navigate to mscorlib( assembly in the drop down 4. Once selected in the list below expand the system namespace and choose GC class. 5. Once this is done you can choose the Collect() static method. 6. You can unreserve the callback VI by running this VI.

Reported Version: 2013 SP1    Resolved Version: N/A    Added: 05/07/2014


Notice that this is valid for LabVIEW 2013, though I had no issues running this example on LabVIEW 2015.  I got this information from the following url:


Hope this helps!


Message 4 of 31

Sweet find.  I'll give this a shot and let you know how it turns out.  It could save a ton of time in development from having to close and re-open projects constantly.  Thanks for the link!

0 Kudos
Message 5 of 31

Works great, saves a TON of time now editing and coding this project.  thanks for the solution!

0 Kudos
Message 6 of 31

Glad to hear it Mike!  Good luck with the rest of the project.

0 Kudos
Message 7 of 31

Hi Mada_17,


Thank you for the workaround.  This is still happening in LabVIEW 16.  I've got a .NET callback that won't stop on its own.  After using the invoke node as suggested, the callback stops when the calling VI stops.  I wasn't able to run my code twice in a row without closing all the VIs and re-opening them.


Thank you again,



0 Kudos
Message 8 of 31

Hi Mike,


Sorry to hear that you are having issues with this.  According to the list of know issues in 2016, the work around is still valid:


It sounds like it still works, but can you further describe the issue you are having?





0 Kudos
Message 9 of 31

Incredibly useful workaround, but i seem to miss something in the implementation.

This class constructor is not public...



Do i miss something, or has mscorlib changed over the course of last few years?

(Win10, LV16, .NET 4.0)

"When I need the side of a building to view all the code..." -Mark Yedinak
"...when you need a navagation window to view the navagation window..." -Jeff Bohrer
0 Kudos
Message 10 of 31