Anti sleep function (QTP, VBScript, MercuryTimer, DeviceReplay)

Posted by Albert Gareev on Aug 18, 2009 | Categories: RobustnessSource code

Sometimes a PC goes to sleep, launches screensaver or locks the desktop during a long synchronization periods or other GUI inactivity periods. Adding the function below makes the script periodically moving mouse to avoid breaking of the execution. Place the call to the function within your time-consuming loops and custom synchronization functions.

To improve performance you may want to move Set objDeviceReplay = CreateObject(“Mercury.DeviceReplay”) statement to a global initialization function and do not create/release the object constantly.

Private Const SleepTime_Max = 300 ' 5 minutes
Public Function AntiSleep()
Dim iter
Dim objTimer
Dim objDeviceReplay
Dim intTimeElapsed

 Set objTimer = MercuryTimers("AntiSleep")
 intTimeElapsed = CInt(objTimer.ElapsedTime/1000)
 If intTimeElapsed = 0 Then
  Exit Function
 End If

 If intTimeElapsed < SleepTime_Max Then
  Exit Function
 End If

Set objDeviceReplay = CreateObject("Mercury.DeviceReplay")

 For iter = 100 To 110
   objDeviceReplay.MouseMove iter,300


Set objDeviceReplay = Nothing

End Function

  • 6 responses to "Anti sleep function (QTP, VBScript, MercuryTimer, DeviceReplay)"

  • Joe Strazzere
    18th August 2009 at 17:12

    I always turn off screensavers from machines where I’m performing automated testing. That way this problem never occurs.

    In some scripting languages, you can turn it off programmatically, test, then turn it back on.

    (I’m not sure moving the mouse to keep the system from sleeping is always wise. What if the pointer location is significant to your system-under-test?)

  • Albert Gareev
    19th August 2009 at 9:15

    Hi Joe,

    Don’t be surprised, in many large organizations security policies are very strict! You won’t even have the access to screensaver settings.
    Going further, having screensaver turned off you won’t prevent a machine from going to stand-by mode – it will go to sleep and script waiting for a long generating report will get stopped/failed.
    Regarding _my_ test automation, I have end-users executing scripts on different machines, and the main requirement is to be able to use the script “right now” and “as is”. The more _unnecessary_ manual configuration is required the less user-friendly solution is.

    The workarounds you suggested may still work under some circumstances… I just think it’s much simpler not having the problem at all.

    (As for the last note, I believe you didn’t really think it through. I’m afraid to imagine a program-under-test that prohibits a user from moving mouse anytime he wants.)


  • Joe Strazzere
    19th August 2009 at 19:45

    “(As for the last note, I believe you didn’t really think it through. I’m afraid to imagine a program-under-test that prohibits a user from moving mouse anytime he wants.)”

    I didn’t say “prohibits”.
    I know sites that have different behavior, depending on where the mouse pointer is placed. So do you, I’m sure.

    Take, for example *this* site. With all the SnapShot popups, if you move the mouse into the wrong spot, something (perhaps unaccounted for) happens.

    Anyway, glad this method works for you.


  • Albert Gareev
    20th August 2009 at 8:59

    I finally think I should provide some more details.

    The most common example.

    “Generate report” button has been pressed.
    Depending on the query (e.g. range of accounts and date range) AND Test Environment performance, generation of report takes from 1 minute to 20 minutes while a typical screensaver setting is 10 minutes, and stand-by setting is 20 minutes.

    While report is being generated by the server on the back-end the Application-Under-Test is busy and not interacting with the user. It is not supposed to behave anyhow at the front-end until the report is generated.

    So the script is simply waiting in the synchronization loop. Moving mouse won’t trigger anything.

    Properly created scripts are successfully used through the all testing phases, and executed on different computers by different users without programming skills. All they want is to get test results with minimal manual efforts spent and definitely not changing computer configuration, especially on UAT which usually mimics all the settings from production.

    So instead of excusing the script for failing test cases is better to use proper synchronization function.
    And, by the way, the moving trajectory is all under control: DeviceReplay.MouseMove X,Y. So you can move the cursor over taskbar or title bar to be in complete safety.


  • Narayanan
    11th March 2016 at 1:09

    Thanks, It helped me to resolve the issue.

  • Lior
    17th April 2018 at 0:59

    Thank-you for the help. Will check this out!

  • Leave a Reply

    * Required
    ** Your Email is never shared

Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported
This work by Albert Gareev is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported.