Screensaver, Sleep, Workstation Lock, and Power-Save Disabling

[JLogan3o13]

   As someone who has worked in a medical IT environment, I know the issues with legacy applications. It really sounds like you are doing 10 times the work for not wanting to investigate the proper approach to installing this application. If this installation is that difficult to manage, rather than some seat-of-the-pants disabling of standby you should be looking into investing the time and energy into properly repackaging the application into an MSI that then could be run silently.

   Even the most difficult application probably could have been finished, just in the time you've spent seeking this answer over the past couple of days.

[twp]

   As someone who has worked in a medical IT environment, I know the issues with legacy applications. It really sounds like you are doing 10 times the work for not wanting to investigate the proper approach to installing this application. If this installation is that difficult to manage, rather than some seat-of-the-pants disabling of standby you should be looking into investing the time and energy into properly repackaging the application into an MSI that then could be run silently.

   Even the most difficult application probably could have been finished, just in the time you've spent seeking this answer over the past couple of days.

There is now way to make this one silent!

[TXTechie]

I have worked in the Systems Management field of IT (deploying customized software packages to many PCs) for several years and while I prescribe to the idea that repackaging is a last resort, it will - indeed - allow you to deploy this (or any software installation) silently.

Repackaging is an attempt to capture the changes made by a legacy installation and then "repackage" it into a standard Windows Installer (MSI) based installation that provides all of the features of a standard Windows Installer based installation (including all of the command-line switches for installing it quietly or silently).

To get an idea of what repackaging can do for you (and it may even provide all you need for this particular job), check out the free AppDeploy Repackager.

[JLogan3o13]

I think we have debated our opposing views before, TXTechie. I personally look at repackaging as the first resort, rather than the last.  

[TXTechie]

I don't think we debated, just stated our views/perspectives. Also, you are obviously not alone in your particular perspective. I used to do repackaging (for all deployed software), but it does have its drawbacks and disadvantages. Even Microsoft doesn't use it for all of their software installations.

I highly respect your advice/input/feedback and I'm glad you are an MVP on the AutoIt Forums! I have learned (and I'm sure I'll continue to learn) from you here.

[twp]

I have tested the following Functions and it seems to work. The desktop does not freeze during installation. However, I have another smal problem. The user can still lock the computer manually. How do I prevent it while the script is running?

Func _PowerKeepAlive()
#cs
    ; Flags:
    ;    ES_SYSTEM_REQUIRED  (0x01) -> Resets system Idle timer
    ;    ES_DISPLAY_REQUIRED (0x02) -> Resets display Idle timer
    ;    ES_CONTINUOUS (0x80000000) -> Forces 'continuous mode' -> the above 2 will not need to continuously be reset
#ce
    Local $aRet=DllCall('kernel32.dll','long','SetThreadExecutionState','long',0x80000003)
    If @error Then Return SetError(2,@error,0x80000000)
    Return $aRet[0]    ; Previous state (typically 0x80000000 [-2147483648])
EndFunc

Func _PowerResetState()
    ; Flag:    ES_CONTINUOUS (0x80000000) -> (default) -> used alone, it resets timers & allows regular sleep/power-savings mode
    Local $aRet=DllCall('kernel32.dll','long','SetThreadExecutionState','long',0x80000000)
    If @error Then Return SetError(2,@error,0x80000000)
    Return $aRet[0]    ; Previous state
EndFunc

[BrewManNH]

BlockInput

[Bert]

A simple way to deal with the problem is start two processes. The first process (exe) only has the code to move the mouse every 60 seconds. The second process performs the install. Once the install is complete the mouse process closes. That way the OP does not need to modify his original script that does the install. It is a simple matter for the mouse script to look for the install script exe and if it is running or not. If it has closed the the mouse script would exit.

To keep the users from locking the PC manually, that is a different problem. My best suggestion is to use a splash screen with a message for the user to not touch the keyboard or mouse while the install runs.

I looked at your example. Are you using controlsend in your script or send? Using send is never a good idea during installs for if the window loses focus then the script fails.

Edited February 27, 2014 by MBALZESHARI