Determine when callback VI completes

[cbfsystems]

I have written an application that creates a notifier icon (icon in the system tray).  The notifier icon has a context menu with a menu item to exit the abort the top level VI in the application.  When the exit menu item is selected, a callback VI is called to take care of the exit procedures.  The exit routine needs to do a number of things such as unregistering events associated with the context menu, making the notifier icon invisible, disposing the notifier icon and closing the reference to it, and aborting the top level VI.  Putting all these tasks directly in the callback VI does not work.  I tried putting these tasks in another subVI, which I have called Exit.vi, that is started by the callback VI using a Run VI method in an invoke node with "Wait until done" set to false"  This seems to work sometimes, but occasionally hangs my application for a while and sometimes crashes LabView.  The problem seems to be related to starting the various tasks such as unregistering events before the callback VI has completed.  If I add a bit of delay in Exit.vi before starting the other tasks, everything seems to work fine.  If I add a bit of delay in the callback VI after starting Exit.vi and no delay in Exit.vi, there is trouble every time I try to exit.

Add some delay in Exit.vi seems to work, but the amount of delay required is unknown and this is not a deterministic way to handle the situation.  Is there a way that Exit.vi can determine when the callback VI has completed?  Exit.vi could then wait until the callback VI was done and then gracefully close everything down. 

[viScience]

Pass it a reference to the callback vi and then check its run state or pass it a notification/occurance

refnum which gets triggered just before callback vi stops.

[cbfsystems]

I don't think that either of these solutions will work reliably.  A static VI reference is passed to the Reg Event Callback node when registering the click event on the Exit menu item.  When using this static VI reference, the run state of the callback VI becomes "Running" as soon as the main VI is started even though the callback VI has not been called yet so it is not possible to tell from this property when it is called or completes.

Using a notifier or an occurrence doesn't seem like it would reliably tell me when the callback VI has completed.  If I understand correctly, the callback VI would set an occurrence or send a notification just before it completes and "Exit.vi" would wait on occurrence or wait on notification before performing its various shutdown tasks.  Since the callback VI has not quite terminated when it sends sets the occurrence/notification and Exit.vi is running in parallel with the callback VI, it is still possible that Exit.vi may start its shutdown tasks before the callback VI has completed.

Any other thoughts about how to do this?

[viScience]

What is the difference in events between setting a notification just before stopping a vi and the actual point that the vi stops running? 

I am not sure why you should need 2 levels of async vi's running.  Could you explain why you cannot do all your housekeeping in the callback vi?

[cbfsystems]

One of the issues with putting the various shutdown tasks directly in the callback VI is that my application stalls if the notifier icon events are unregistered while the callback VI is still running.  Also, if the top level VI is aborted from within the callback VI, VERY bad things happen and the computer has to be rebooted.  Apparently some of these shutdown tasks must be done after the callback VI has stopped running, not just after it has executed all the code on its block diagram.  I investigated this by putting a bit of a delay into the callback routine that executed after it had done all its other tasks including calling Exit.vi.  When this was done, my application stalled or crashed every time.  Admittedly the delay was code on the callback block diagram, but all its other code tasks had been completed before executing the delay.

[viScience]

What if you could send your main application a message that it needs to start shutting down.  That way it could just start performing these operations itself in one of its own async loops.

Some common methods for this are by using queues or user events.  If you need to message from one app to another then use network shared variables or raw tcpip.  Many have gone down this path - do a search for producer consumer design patterns and see what comes up.  In general I would avoid ever using the abort method via vi server, much better to message an app to tell it to shut down.

[cbfsystems]

It seems that there is still an issue of the main application getting the message to shutdown and starting the shutdown sequence before callback VI completes.  I need to know that the callback VI has completed, but it can't send a message after it has completed.  If it sends a message before it completes, then the message could be received and acted upon before the callback completes.

The idea of monitoring the run state of the callback VI seems like what I want if it were not for the problem of the run state always being "Running" when a static VI reference is used.  There must be some way around this problem or another acceptable way of dealing with exiting the application.  I wish I knew what it was.

[viScience]

Still not understanding why the callback needs to do anything other than send a message to the main app to shutdown?

[cbfsystems]

If the main application starts to shutdown before the callback has completed, bad things happen such as the application stalling or crashing.  If I am running the application in the development environment, then the development environment sometimes crashes.

[viScience]

I presume you are using an activex callback.  If the callback vi sends the main app a user event then you should be able to respond directly to this in the apps event structure and then start closing referrences.  You should first close the reference to the Automation Open and then Unregister the Event Callback.  If it was just a matter of waiting for the callback to finish then a simple 1s delay would be more than enough although you should not need any delay at all.   I think the problem is elsewhere.