PureBasic Forums - English

Hi,

For quite a while I have been using this procedure to keep PC's awake during program run.
I am now moving the program onto 64bit exclusively and I am concerned how this might effect things as this procedure is using the 32bit Kernel Library.

The procedure still works on 64bit but I would like to know if there is a 64bit way of doing the same.

Thanks

Don't let the filename fool you. Shifting to x64 PB IDE Compiler, it'll use \System32\kernel32.dll instead of \SysWOW64\kernel32.dll

They aren't the same;

44aac4307be433e5c730124eb9043543 \SysWOW64\kernel32.dll
1c9c6933a94c594de7366124b4dd6075 \System32\kernel32.dll

I've seen lots of apps in software sites that prevent sleeping and all they do is simulate a keypress periodically, like pressing Ctrl. They get good ratings from their users so I assume they must work. So, to prevent sleeping on Windows, it can be as simple as periodically doing this:

@Dude

Holy hell. No, no no no no.

Ever stop and think? What happens if the user is typing in a chat and by chance he press the v key at the same time as the program sends Ctrl. Boom the users secret shame is pasted for the world to see.


MicroSoft created a API specifically for this which SniffTheGlove is correctly using.


I did't even know that sending ghost control events was a thing. No wonder people complain that windows is crappy if programs do shit like that.

@SniffTheGlove

Do you really need the display to be on?
ES_DISPLAY_REQUIRED should only be needed for video players or programs that continuously shows status reports or changing information to the user.

Do note that for media (like music and video) there exists other APIs that let you specify if the program is a media app, this should improve latency for audio and video (the process is classed as a media process).
Also note that for a video app you may want to ensure/allow the display to go black when the video is paused. Screen burn in is less of an issue now with LCD/LCD-LED/Plasma (unsure about OLED) than back in the old days of CRTs.

@Roger: You've been spending too much time with that Rescator rogue!

Some potentially useful info here:https://msdn.microsoft.com/en-us/librar ... s.85).aspx

netmaestro wrote:@Roger: You've been spending too much time with that Rescator rogue!

netmaestro wrote:Some potentially useful info here:https://msdn.microsoft.com/en-us/librar ... s.85).aspx

What has the broadcast of the power status got to do with keybd_event, you confused me somewhat with this.
As far as I know keybd_event just blindly sends a keyboard event to the keyboard driver/system in general and not just that one window.
https://msdn.microsoft.com/en-us/librar ... p/ms646304

Not a thing, I'm just looking at alternatives for a more professional approach to keeping an application alive when the OS tries to go to sleep. Responding to changes in the power status seems logical, as that's probably the whole purpose of the broadcast in the first place.

Roger Hågensen wrote:Ever stop and think? What happens if the user is typing in a chat and by chance he press the v key at the same time as the program sends Ctrl

Well, if you think about it, the idea is that the PC waits for an idle state first, and THEN does the simulated keystrokes to stop it actually sleeping. Thus, the user won't actively be typing anything during this period. Remember, the "keep awake" thing is for when nobody is using the PC at the time.

@Dude

One word (two actually): Race condition

At the moment the idle is triggered the user may type again.
if the code is slow, from the time the idle detection is triggered until your code send the fake key presses the user may already be holding down a key