01-11-2023 06:30 AM
hello,
i have a program implemented in LabVIEW, there is some script that should be run after finishing this program or terminated.
i can handle one case when the user press stop from the vi, but there are another two cases I can't handle
1: when the user click on "abort execution from Toolbar", how can I know the user pressed ("note I shouldn't remove this button")
2: when the user ends the program from task manager
any idea about handling these two cases?
01-11-2023 08:20 AM
Hi Peter,
@Peterboshra wrote:
1: when the user click on "abort execution from Toolbar", how can I know the user pressed ("note I shouldn't remove this button")
Simple solution: hide the toolbar! Your users should NEVER see it…
@Peterboshra wrote:
2: when the user ends the program from task manager
Why should your user want to do that?
Have you tried to use an event structure to handle those Application events?
01-11-2023 08:31 AM
i am handling the edge cases that could be happened, I should run some program to reset the hardware components to the initial state so I should handle any edge case that terminate the program
01-11-2023 09:10 AM
Yes, a deployed application should never show the toolbar. It should not even have a stop button on the front panel, because we already have the [X] in the upper right that is universally known to end a program. To intercept that, you simply need a "panel close?", "application close?" etc. filtering event that discards the event, initiates the shutdown sequence, then closes the program once everything is in order.
Killing a process from the task manager should only be needed if the program is poorly written and buggy and is in an unknown state where it no longer correctly runs (deadlock, partial crash, etc.), so trying to handle that in the same program seems like a poor choice. You also need to deal with the possibility that the computer crashes.
Maybe you need a hardware safety switch or some independent watchdog program running on separate hardware that pulls that safety switch when an unusual state is detected (e.g. when it stops receiving regular "I'm alive" messages from your program over the network.
Of course when the program starts, it needs to correctly initialize all hardware and not assume a defined state. How dangerous is a condition where shutdown is incomplete (deadly voltages? overheating? etc.)
01-11-2023 09:22 AM - edited 01-11-2023 09:23 AM
@Peterboshra wrote:1: when the user click on "abort execution from Toolbar", how can I know the user pressed ("note I shouldn't remove this button")
2: when the user ends the program from task manager
any idea about handling these two cases?
1. You should NEVER show the abort execution button to the end user.
2. There is nothing you can do for this case short of some type of hardware watchdog that can put your UUT into a safe state if the LabVIEW program does not "pet the dog".
01-11-2023 10:36 AM
@Peterboshra wrote:1: when the user click on "abort execution from Toolbar", how can I know the user pressed ("note I shouldn't remove this button")
The VI can create a queue and pass it's reference to a dynamically started VI. That VI then dequeues a queue element, and that will basically hang forever (because no element is enqueued).
If the VI dies for whichever reason, the dequeue stops waiting, and returns an error. The dynamic VI can then take actions.
I agree that your code shouldn't do this. However, during development, I like that I can abort my code. And if the code locates dynamic resources, I do want (and sometimes require) that those resources are freed. A dynamic VI waiting for a queue created in the caller does this.
@Peterboshra wrote:2: when the user ends the program from task manager
The process can't do anything when it's killed.
You'd need a 2nd process.
01-11-2023 01:07 PM
@GerdW wrote:
Hi Peter,
@Peterboshra wrote:
1: when the user click on "abort execution from Toolbar", how can I know the user pressed ("note I shouldn't remove this button")
Simple solution: hide the toolbar! Your users should NEVER see it…
Depends on who the users are. Sometimes I create tools for developers. In those cases, I leave the toolbar, with the abort button; -- unless I really need to enforce a shutdown.
01-11-2023 08:14 PM
FYI Ctrl+. is always available whether toolbar/menu is displayed or not. #TeamNeverToolbarOnUIs Of course I'm lazy and don't turn off toolbars unless I'm sharing/deploying and then I'll turn them off for anything I display. To me that's either valuable real estate or open to causing headaches due to everything else not cleanly closing or orphaning stuff running async so abort usually means I'm going to need to completely close LabVIEW to kill everything off anyway.
For OP, it sounds like you want to create a separate program that runs in the background. While the LabVIEW program is running, the LV program can periodically communicate to the other program and then anytime that stops for too long, the background app can run the needed script. There are a bunch of edge cases of how LV code can stop, crash, be aborted, or killed to really do much of anything other than something like a watchdog process.
01-11-2023 09:09 PM
I tried to experiment with the possibility and found out that ending a task from Task Manager is actually the same as clicking the top right close button. If you disable the Abort button and handle the stop with Panel Close? event, you should be good for most use cases.
01-12-2023 12:49 AM
That will be true as long as the application gracefully handles it. If it doesn't close at that point, Windows can kill the process ungracefully. It'll depend on what cases you need to cover and why they're going into task manager to stop the app; presumably because it's hung and not responding to normal close requests.