text: 11-22-2015 08:57 PM
  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?
  Solved! Go to Solution.
  11-22-2015 09:06 PM
  11-23-2015 08:20 AM
  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.
  11-23-2015 01:34 PM
  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 Callback.vi" example, after stopping the main example VI, the "Callback - EventHappened.vi" 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(4.0.0.0) 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.
  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!
  11-23-2015 02:02 PM
  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!
  11-23-2015 08:12 PM
  Works great, saves a TON of time now editing and coding this project. thanks for the solution!
  11-24-2015 07:24 AM
  Glad to hear it Mike! Good luck with the rest of the project.
  11-01-2016 11:22 AM
  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,
  Randy
  11-01-2016 11:54 AM - edited 11-01-2016 11:54 AM
  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?
  03-17-2018 10:10 AM
  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)