When would you actually use these? Aborting a VI is only done during debugging, and under normal circumstances you should NEVER use the Abort button in the toolbar to stop a VI.
Likewise, pausing a VI is only done during debugging.
When would you use a cloning event?
These seem to be events that would only be generated during development, and not in a run-time environment, or even in a built application, so I'm not sure where or how these are supposed to be used. Can you provide more information as to how you think these would be used?
Cloning during run time when you call a reentrant VI dynamically, you get a new clone. Another process could track how many/when these were created - several useful reasons for this.
Also, when a new VI is spawned from a template. Definitely do this during run time with the old GOOP model. I don't know if this counts as a 'clone' or not, but same idea.
During development and code testing is exactly right - I have some module testing automated. If I have a stuck VI (module) I can abort it with a reference to that VI. I DO want my main app to know it was aborted to take appropriate action.
"Under Normal Circumstances". Circumstances at some job sites are definitely not 'normal'. LabVIEW is treated as a test application in many environments, and that's not going to change. I've seen places where the restrictions on how you treated LabVIEW were a nightmare - no deployed executables, wide-open access to code on the floor, no hiding the Abort button.... Users of those apps would use the ABORT when they have an issue and can't find someone to assist and kill the VI, and some that will use it for convenience no matter how much browbeating they endured. Monitoring or tracking those events might be useful.
There might be some legitimate use cases for the events you are proposing. But I don't know if some of them can even be implemented in a logical manner. Specifically VI aborted and VI paused.
How can you have an event that handles a VI being aborted? If you abort the VI, that means you want it to stop NOW. And then it will no longer be in any state of execution where it could run any further code. (Hey stop now, but first before you do that, I want you to execute some other code. ) Suppose that additional code has issues. How do you abort that? Where you your real abort function then?
Likewise "paused". How can you execute code if you want it to pause?
Any use case that involves those two means you really need a more sophisticated architecture than relying on the pause, run, and abort buttons in the LV environment.
@Ravens: At first I thought what you were thinking, but it seems the suggestion is targeted toward "another process" (VI) subscribing to these events, not a VI subscribing to it's own events
The aborted code wouldn't run anything - you would use references to the aborted or paused code that another monitoring process would handle.
Back to automated code validation. Let's say I use a launcher to execute VIs from an array of references. Furthermore, I monitor their progress and have access to some of their internal functions (queues, timed loops, whatever). If, during the course of executing them, I infer that that the VI is 'stuck' (missing timeout periods has been the most obvious sign), so I decide to Abort that particular VI, via its reference.
I could 'know' that I aborted it and perform the appropriate action right then and there. However, it would be nice to have a separate process monitor that, to timestamp and give reports, or any number of things.
You know, when I was typing that message, I was thinking of adding the comment that of course it had to be some sort of dynamic event where another VI has to subscribe to the event of a different VI aborting or being paused. But then I completely forgot to mention it. Of course that still means a bit more complicated architecture.
It has been a very bad week at work so far, and I'm just trying to put some time into the forums to feel productive and hopefully help someone else and take my mind off other things. My motivation is at an all time low right now.
I already kudos'd this on day 1 just for "Execution State Changed" -- I'd love to have an easier way to detect when I kick off an Run VI method for it to signal it is finished without me having to create a mechanism to signal that back to the caller.
Sometimes when debugging, I would like to have more programmatic control. A VI Paused event would let me set a breakpoint on my real VI, and in a debug VI, watch for VI Paused. When that event triggered, I could programmatically enable Execution Highlighting and then unpause the VI. Not as nice as actually having enable/disable exec highlite points built into LV, but I'll take any improvement in this area.
I can't claim any use for VI Cloned.
As for "VI Aborted" event... I have been intrigued for a while now about ways of making effective, healthy use of Abort. A common problem in LV programming is to have an Emergency Stop button that kills whatever is currently executing. Programming such a button to respond timely is HARD. However, LabVIEW already has code level support for the Abort button or -- more importantly -- the Abort VI method in VI Server. The commonly mentioned problem with using Abort is that it leaves your hardware or your database or your files in a potentially bad state. But suppose you have a Caller VI that launches a subVI dynamically using the Run VI method. The as the subVI runs, it sends messages to the caller (through a queue), saying "I'm now working on this" and "finished that". A big master STOP button on the Caller VI could -- in theory -- call the Abort VI method of the subVI and then run cleanup code to reset hardware/database/files because it knows what was going on in the subVI. See, the problem with abort is that it stops all your code from running. When you can abort just one thread of execution and then knowingly cleanup the results, well, you'd essentially be in a world not unlike the exception throwing that other programming languages use quite effectivly when talking to hardware/databases/files/etc. Calling "Abort VI" is only half the problem. You have to have some signal that says, "Ok, that VI heard your abort and is now done." This new event would provide that.
Any idea that has received less than 5 kudos within 5 years after posting will be automatically declined.