prevent screensaver from activating 3

[adumitrescu]

Hello,
I would like to create a small app that keeps the WinXP screensaver from activating. There are many posts with the same suggestions: send keys, move the mouse pointer. I've done both using sendkeys() and setcursorpos(). I get the desired effect on the screen, BUT the screensaver still kicks in. Clearly this faked action is not counting to the screensaver routine.
Disabling the actual screensaver through the registry is not an option for me.

Surely there is a lower-level function (Win API?) that injects a keystroke or mouse movement that the screensaver routine will detect?

Has anyone found a solid answer to this FAQ?
-with thanks.

 

[trollacious]

Did you make sure that the time limit for the screen saver to kick in is greater than the time limit for moving the mouse?

I ran into the same thing in the office where I work, and wrote something using AutoIT that has handled this to the satisfaction of several people in the office.

It always helps if you show your code, too.

Lee

 

[strongm]

>Disabling the actual screensaver through the registry

Why would you do it through the registry? Why wouldn't you just disable it through Display properties?

Unless, of course, you are trying to circumvent group policy - in which case I can't help.

 

[adumitrescu]

Ahhhhh....... nothing is ever easy.
1. Yes, screensaver (5 mins) is greater than delay (30 secs) between automated mouse pointer movements using setcursorpos.
2. I'm not trying to break into any banks. If you believe that circumventing a screensaver activation is a worthy of a "then I can't help you" position, then why did you even post? The time to pull out the moral compass is when someone desires to "break into a system without a password". Security is never black and white - this is what I learned when I completed my CISSP certification.

Back to the technical discussion.
I have been pursuing the SendInput function, but cannot find any clean examples. In my case, I'm hoping to send a simple CURSOR_UP - but then nothing is simple with WinXP!
-thanks

 

[strongm]

> Security is never black and white

Well in that case I'm sure that you can make a case to whoever is imposing the Group Policy to make an exception for you.

 

[BobRodes]

<The time to pull out the moral compass is when someone desires to "break into a system without a password".

<security is never black and white

The only way in which the above statements don't contradict each other is if it is never time to pull out the moral compass.

 

[adumitrescu]

Good grief. :-(

In the interest of what Tek-Tips means to me, here is a solution to my original question (with thanks to other technical forums out there):

It seems that SendInput does something that SendKeys does not, and calls to it are detected by screen saver routines as mouse activity. Below is the VB6 source. Open a new project, drag a timer object to the form, and set the Timer1 to a 10 second fire (interval = 10000). What is convenient is that the actual routine doesn't need to move the mouse pointer at all. You just call with with a move amount of 0, so the event in injected into the mouse input stream, but no change occurs. Nice.

Option Explicit

Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (pDst As Any, pSrc As Any, ByVal ByteLen As Long)
Private Declare Function SendInput Lib "user32.dll" (ByVal nInputs As Long, pInputs As INPUT_TYPE, ByVal cbSize As Long) As Long

Private Const MOUSEEVENTF_MOVE = &H1
Private Const INPUT_MOUSE = 0

Private Type MOUSEINPUT
  dx As Long
  dy As Long
  mouseData As Long
  dwFlags As Long
  dwtime As Long
  dwExtraInfo As Long
End Type

Private Type INPUT_TYPE
  dwType As Long
  xi(0 To 23) As Byte
End Type

Private inputEvent(0) As INPUT_TYPE

Private Sub Form_Load()
   Dim mouseEvent As MOUSEINPUT
   
   ' Load up the event record
   mouseEvent.dx = 0
   mouseEvent.dy = 0
   mouseEvent.mouseData = 0
   mouseEvent.dwFlags = MOUSEEVENTF_MOVE
   mouseEvent.dwtime = 0
   mouseEvent.dwExtraInfo = 0
    
   ' Copy the record into the input array
   inputEvent(0).dwType = INPUT_MOUSE
   CopyMemory inputEvent(0).xi(0), mouseEvent, Len(mouseEvent)
    
End Sub

Private Sub Timer1_Timer()
    Dim intX As Integer
    
    intX = SendInput(1, inputEvent(0), Len(inputEvent(0)))
End Sub

 

[BobRodes]

Interesting...and I was just having fun with you, didn't mean to amplify the prickliness. So, now I'm thinking about setting the timer's interval property based on the setting for when the computer goes into screen saver mode. If anyone knows a WMI object offhand that returns that setting, perhaps you could mention it and save me some wandering around.

 

[SBerthold]

[COLOR=blue]
Public Sub ScreensaveTimeOut()
    Dim strComputer As String
    Dim objWMIService As Object
    Dim colItems As Variant, objItem As Variant
    
    strComputer = "."
    Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
    Set colItems = objWMIService.ExecQuery("Select * from Win32_Desktop")
    For Each objItem In colItems
        Debug.Print objItem.Name & ": Screen Saver Timeout: " & objItem.ScreenSaverTimeout
    Next
End Sub
[/color]

http://msdn2.microsoft.com/en-us/library/aa394591(VS.85).aspx

http://msdn2.microsoft.com/en-us/library/aa394121.aspx

 

[SBerthold]

You asked for a WMI object, but could also just use the SystemParametersInfo API

 

[JoeAtWork]

I have to admit that I'm curious as well as to the need of overriding default security settings. This is not based on "morality" or "dogma", but in the interest of keeping things as simple as possible.

Presumably the security policy was implemented with some due consideration, and perhaps even to comply with laws and regulations. Since you do not seem to have the necessary permissions to change the security settings, it appears you are acting unilaterally to circumvent a policy put in place by others who perhaps have more information than you as to the necessity of the policy.

Security policy is not just to keep criminals from "breaking into the bank", but is also to keep the well-intentioned from accidentally causing disaster.

I'm not saying what you are doing is wrong, because I don't know the details of your particular circumstances. But I think StrongM has a very good point about not circumventing the policy settings.

 

[trollacious]

Where I work, the policy is set by a home office for all users. In the tech support area, we often are in some kind of video conference with clients and trainers for long periods of time. If we don't remember to move the mouse, the screensaver kicks in, locks us out, and it takes time and is distracting to have to log back into our own computers while we're sitting there. While in the ideal world a petition to the IT people would give us special exemptions from this policy, in real life it doesn't necessarily happen that way. Yes, we could setup a timer to remind us after so many minutes to move the mouse or face the password-protected screensaver, but that's a separate distraction that is silly.

I realize that the policy is supposed to protect computers from unauthorized use while users are away from them, but everyone in the office locks their computers when they leave them for any period of time anyway. Not all employees are as tech-savvy, and the policy is for their protection.

I remember in the military that there were 3 official ways of doing something: your way, my way, and the military way. Practically, though, there was often also the way that actually got the job done the most efficiently. Bureaucracy does well in creating (needed) structure, but that sometimes gets in the way of the people who actually are charged with getting the job done.

Lee

 

[JoeAtWork]

Yeah, I can see that as being a genuine reason. I'm surprised that the video conference software doesn't already take care of that - if I leave a video running on Windows Media Player, my screen saver does not kick in (as far as I remember).

The OP inferred that as long as his goal wasn't to "steal passwords", then circumventing security was OK. I wanted to point out that even if your intentions are well meaning, that alone is not a good reason to circumvent a security policy if at all possible. Disasters sometimes occur from people with the best of intentions.

 

[trollacious]

The GoTo products (which we use) don't seem to affect the screensaver's timer. It can be VERY frustrating when sitting in on a presentation and taking notes on paper to suddenly have to break your concentration to log back into your screen and try to catch up to what was missed.

I used AutoIT because it's similar to BASIC in commands and syntax, and version 3 allows you to compile scripts to executables. The script I have is 20 lines long (not including white space and comments), includes checking to make sure there's only one instance of the program running, and displays nothing on the screen because it has no forms or windows.

Lee

 

[BobRodes]

<You asked for a WMI object, but could also just use the SystemParametersInfo API

I prefer to think of that as I could use the SystemParametersInfo API, but could also just use the WMI object.

In any case, the information can be used to more accurately set the Timer's Interval property.

 

[Tranman]

Interesting thread. As to why you would want to sidestep a group policy, here's my reason.

I have a user who creates and updates layers in Arcview. The updating can take several hours. If, at any point in the process, the screen saver goes active, all work is lost and he has to start over again. Anyone can understand what a pain in the a** this is for him. Not only does he have to eat lunch at his desk, and never start an update when he has a meeting scheduled, he also can't go home until the updates finish.

You can also understand that this is only a problem because Arcview is a crappy program, but that's what we've got. Our support group wants him to submit a written request every time he wants them to turn off his screen saver.

So here's my thought. Instead of just writing something that jiggles the mouse and keeps the system alive, it could also sense "actual" mouse movement (probably by position each timer event) and if the mouse has moved, activate the screen saver. The net effect would be that he could leave an update running at night when he goes home, knowing that it would be finished by the time he returns, and if anyone messes with his mouse, the screen saver kicks in. So then he could leave his update routine running when he leaves work, and still have security. Of course, this would not help for the lunchtime situation--he would have to be in a position to not touch the mouse until the routine finished, but at least he could run into the night after he leaves.

Any thoughts?

A star to you, cutefez, not for your code, but for maintaining your mature attitude in the face of a less-than- supportive response.

"Adam was not alone in the Garden of Eden, however,...much is due to Eve, the first woman, and Satan, the first consultant." Mark Twain

 

[strongm]

>Our support group wants him to submit a written request every time he wants them to turn off his screen saver

The issue, therefore, is with the company procedures, not with the Group Policy itself.

 

[dglienna]

Might need Terminal Server for that guy. Install Arcview on the server (if they let you)

-David
2006, 2007 & 2008 Microsoft Most Valuable Professional (VB)
2006 Dell Certified System Professional (CSP)

 

[trollacious]

If the guy were to accidentally bump the mouse after activating the program, then his work would again be lost. If he were to lock his computer's keyboard and screen, would that interfere with the upload process going on behind the scenes?

Lee