Tie Daemon Lifetime to Caller?

[TurboPhil]

Does anybody have any clever suggestions for handling brat VI/daemon lifetime? I'd love a clean way to launch a helper subvi that will automatically stop when its caller stops.

As an example, I have a brat VI that handles autosizing columns in a MCLB that I have a lot of use cases for. It's super easy to drop down in any VI that I want to implement the autosizing feature. But since it is running with a while loop watching for pane size events, I need a way to make sure it stops when its caller stops.

The best solution I have come up with so far is requiring the parent to create a dynamic shutdown event prior to calling the brat VI, then hand the reference into the brat, then fire the event when it stops, so the brat will also stop. But that means my nice clean "just drop in this subvi" implementation gets a lot more complicated, and if a developer forgets to fire that event, then the brat never stops and you end up with a hung VI. 

Sure would be nice if there was a way to register for  "VI Execution State Changed" events, so then the brat could register for that event on its caller.

Has anybody come up with a good solution for this problem?

[Darin.K · Accepted solution]

I actually prefer calllback VIs in this situation.  In the .NET palette is the 'Register Event Callback function'.  I would take your MCLB control and create a reference.  From the reference get the 'owning pane' property value and wire it to the 'event' terminal of the REC function and choose the Pane size event.  I would wire the reference to the MCLB to the user parameter.  Now right-click the REC node and select 'Create Callback VI' .  Do your voo-doo inside this callback VI using the passed in references.  Now you have a VI which is called whenever the event fires and goes away when the calling VI is finished with no muss and no fuss.

[TurboPhil]

Thanks for the suggestion, Darin!

I just whipped up a new "brat" VI to handle "zooming"--adjusting font size in string/table/listbox controls--using the scrollwheel event, which leverages a callback VI. 

For ctrl+scrollwheel, I don't think the odds are too great that users will end up firing boatloads of events, so I'm comfortable with a callback for that. But for something like pane sizing, which tends to fire cascades of events in quick succession, I'm a bit scared to lean on callbacks for that...do you have any insight/lessons learned with respect to callbacks of that nature?

[Darin.K]

My experience is that events like PaneSize end up throwing fewer events than I would like and so are not really likely to overwhelm your callback VI.  This is why there is often a bit of choppiness when you try to do manual resizing on-the-fly.  I have yet to see a situation where there is a noticable difference between the Event Structure and a callback VI.  It is really nice to have GUI-only code separated from the business logic.