Trapping DestroyWindow / WM_DESTROY events in AutoIT

[JOlsson]

Hi,

I have used Autoit 3.2.4.9 to create a small GUI application which prompts the logged on user to reboot his/her computer. The application traps WM_CLOSE events so the user can't close the application window using Alt-F4. The normal close/minimize/maximize buttons are also hidden.

However, I haven't found a way to trap WM_DESTROY / DestroyWindow events in AutoIT. Is this possible? When the AutoIT application window receives a WM_DESTROY event the application exits immediately with an error code.

The reason that this is a problem for me is that the AutoIT program is supposed to run as a part of SMS 2003 package installations on Windows XP client computers. The package installations are performed in administrative context, meaning that the installation scripts and the reboot prompt program are run by the System user.

This works well and the reboot prompt is displayed to any logged on user. I would however like to make it impossible for normal users without administrator access to kill the reboot prompt program.

A Windows XP user with no extra privileges can't normally kill processes started by other users. I have verified this in Task Manager using the "Processes" tab and the button "End Process". I can't kill the reboot prompt program that way as a normal user when the program is run by the SMS client service.

But the reboot prompt program is also visible as an application below the "Applications" tab in Task Manager. When I select the application and click the "End Task" button I first get Task Manager's timeout window for unresponsive application. When I click the "End Now" button in this window, the program is terminated.

From what I can tell, Task Manager first attempts to send a WM_CLOSE event to the application when using the "End Task" button. If that doesn't work, the timeout window above is displayed and if the user selects "End Now" a WM_DESTROY event is sent to the application window. Since the latter event isn't handled by AutoIT (at least I haven't found any documentation on how to handle it) the AutoIT program exits with an error code.

So my question to you AutoIT experts/developers out there is: Is there any way in AutoIT to handle the WM_DESTROY event gracefully?

[Ghuul]

I can't help you with WM_DESTROY because I'm not such expert, but have you considered using some very simple service that will do what you need ? Maybe use two scripts - one for main task and second for dialog for users should help. I've bumped into similar problem (I needed users not to be able to kill some scripts) and I ended also with some logoff/shutdown scripts. It wasn't so "nice & pure" but it was working and it was easier then to try "bend" autoit script to do that all. Sorry I can't help you more...

[JOlsson]

I found a workaround somewhat similar to what you describe. Since the AutoIt script can only be killed by a normal user when displaying a GUI I made the script start itself once.

When starting the script the first time, it checks for a command-line parameter which tells it if it is the first copy started or not. If the parameter isn't there, it starts a second copy of itself instead of displaying a GUI. The script passes the extra command-line parameter to the second copy of itself.

The second copy started finds the command-line parameter and displays the GUI. If the second copy is killed by a user, its exit code indicates this and the first copy will attempt to start a new second copy after a short sleep period.

This way a normal user can't kill the reboot prompt script and thereby avoid a forced reboot.