Callback VI remains attached to an active process

[550nm]

The attached example registers a VI for a .NET callback.

After "Unregister"ing and quitting, the callback VI is still "connected" to something, and I have to quit LabVIEW(2014) in order to edit the callback VI.

Note that there seem to be several copies of the (reentrant) callback VI opened in memory (View\Browse Relationships\Reentrant Items).

The troublesome connection happens with the "register" step, but calling "unregister", immediately afterward, doesn't undo the "connection".

How do I "disconnect" the callback from active processes?

Any help is appreciated!

[pauldavey]

I wonder whether you are not calling Dispose on the correct MenuItem refnum? There is an output to the ContextMenu.menuItems() method and perhaps it is the output of that method that you should use when Disposing.

The other consideration is the order in which you (Dispose and) close the refnums. I know when using ActiveX that the order is important - you must close children before their parents, so perhaps try closing the MenuItems before the ContextMenu (enforce it using error wires).

[550nm]

Thanks Paul. That was a good observation regarding MenuItem refnum!

... However, it didn't help!

For the record, the "Close" function of functional-global was disposing the right refnum.  The order of "disposal" is another story.

I'm attaching another example that tries to de-allocate/dispose more "symmetrically" with respect to allocation. (Still no joy.) 

[drjdpowell · Accepted solution]

Had the same problem three days ago.  Googled this solution of calling gc.collect: 

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

Worked for me.

[550nm]

Works! Nice Find, Dr. Powell!

I'd started Googling "VB NotifyIcon MenuItem callback orphaned" - hoping to find a solution on a VB forum (but didn't).

Many, many thanks!