Message board for the users of flat assembler.
> Windows > Screensaver question...
IronFelix 07 Feb 2006, 13:40
Please tell me, is there any WM_xxx message which can be used to determine the moment of screensaver show/hide in Win? And if it is, how to use it?
Flat Assembler is the best!
|07 Feb 2006, 13:40
cod3b453 07 Feb 2006, 19:41
I'm not aware of a system wide notification of a screen saver starting... but, using SystemParametersInfo API, you can use SPI_GETSCREENSAVEACTIVE to determine if there is a screen saver and SPI_GETSCREENSAVERRUNNING will tell you if it is running.
|07 Feb 2006, 19:41
IronFelix 08 Feb 2006, 06:53
Thanks, cod3b453, but i have read this already. This works fine, but i need to know the moment screensaver starting/terminating. I have some program which cathes it, but how...
Thanks again, but the question is still open.
|08 Feb 2006, 06:53
cod3b453 08 Feb 2006, 15:19
Well if you use SetTimer API to set up a timer, you can capture WM_TIMER message and call SystemParamtersInfo API to see if the screen saver is running or not. This will be as accurate as you set the timeout for the timer.
|08 Feb 2006, 15:19
IronFelix 09 Feb 2006, 06:58
This is the obvious decision of course, but it will take CPU resources, that's why i was interested in some message from system... Unfortunately i have to use this method.
Thanks again. I think the question is now closed.
|09 Feb 2006, 06:58
Crukko 09 Feb 2006, 07:43
try this at http://www.apcmag.com/apc/v3.nsf/0/1B0A19FFDF043266CA256DE20008F2E8
Don’t Save That Screen It’s also possible to stop screensavers activating by looking for the message Windows sends before it starts up. This message is WM_SYSCOMMAND, which has a data structure TWMSysCommand. This structure has two important fields, Msg.cmdType and Msg.Result. Declare a private procedure: procedure WMSysCommand (var Msg: TWMSysCommand); message WM_SYSCOMMAND; and implement it like this: procedure TForm1.WMSysCommand (var Msg: TWMSysCommand); begin if Msg.cmdType = SC_ScreenSave then Msg.Result := -1 else inherited end; This code checks to see which system command Windows has issued. If it’s a notification that a screensaver is about to activate, the code sets a field (Result) in the data structure to -1, which means the screensaver request is vetoed. Then Windows won’t allow the screensaver to activate
|09 Feb 2006, 07:43
Crukko 09 Feb 2006, 07:48
I think it's better
How and when saver is executed The following list gives all the situations in which a saver will be launched. * System idle behaviour: When the computer has been idle for a time, and as long as no computer-based-training (CBT) windows are present, the system sends a WM_SYSCOMMAND message to the current foreground window with argument SC_SCREENSAVE. If the active window is not a windows application, or if it gobbles up the message, then nothing further happens. But if the message gets passed on to DefWindowProc then the saver gets executed full-screen. DefWindowProc(WM_SYSCOMMAND,SC_SCREENSAVE) behaves as follows: If there is no currently selected saver in system.ini under the section [boot] with key SCRNSAVE.EXE=, then the message is ignored. If there is a saver listed there, then it is executed full-screen. If running NT, a separate saver desktop is first created with no windows on it. This desktop still has the user's background. The saver runs on this isolated desktop. This means that effects such as corrupting the currently visible windows will not work under NT. With Windows '95 and Plus!, the saver simply executes on the main desktop. In both cases, the saver is started with the argument /s at the IDLE_PRIORITY_CLASS. * Display Properties preview: Whenever the Display Properties control panel is displaying the screen saver tab, and the dialog gains focus, it runs the currently selected saver with argument /p ####, where #### is the decimal representation of the HWND of a parent window. This parent window is the colour of the desktop and it fills the little preview monitor on that dialog page. Your saver should create a child window of it, of the same size, and display itself in this child window. Under Windows '95, if the Display Properties control panel regains focus at any time, then the preview window is first destroyed before the current saver is started in preview mode all over again. If it was your saver that was running as the preview, it should respond to the destruction of its window by terminating. Under NT, this does not happen. Also, obviously, when a different saver is selected in the control panel, then the previous one that was running in the little preview monitor will be destroyed. * Configuration dialog: If the user clicks on the Settings button, then the preview window is destroyed (and so the instance of your saver that was running in preview mode should terminate yourself). Next, the current saver is executed with the argument /c. It should respond to this by executing its dialog as a child of the current foreground window. Once this dialog is finished, the preview inside the monitor will be set running all over again. (This is so that it has the opportunity to re-load any options that might have been changed). If you click on the Configure button, and drag the configuration dialog away, you'll see that the little monitor with preview in the Display Properties control panel is empty. * Change-password dialog: Under '95 and Plus!, if the user clicks on the 'Change Password' button in the Display Properties control panel, the preview window is first destroyed. Then the current saver is executed with argument /a #### where the #### is a decimal representation of the the HWND of the Display Properties dialog. The saver should respond to this by displaying the standard system Change-Password dialog, or by displaying its own, as a child of ####. Once the dialog has finished, the preview inside the monitor will be set running again. Under NT, passwords are managed by the system and the saver is not expected to handle this argument. * Full-screen preview: When the user clicks on the Preview button in the Display Properties dialog, the preview window is destroyed. Then the current saver is executed with argument /s on the current desktop. The saver should respond to this as before by running in full-screen mode. Note that, even under NT, in this case the saver is run on the normal desktop. * Test: When the user double-clicks on your saver's icon it gets executed in Test mode. This is exactly the same as the full-screen preview described immediately above, except that nothing is done to the preview in the Display Properties control panel if it should happen to be active. * Config: When the user right-clicks on your saver's icon it gets executed with no arguments. It should respond by displaying its configuration dialog with NULL as its parent window. (This is different from the Config button mentioned above, where the saver was started with argument /c and was expected to use GetForegroundWindow() as its parent). * Third party applications: There are several third party applications that launch the saver in preview mode with /p ####, or which launch the saver's configuration dialog with /c. Other applications start the saver running as a saver with the command SendMessage(GetForegroundWindow(),WM_SYSCOMMAND,SC_SCREENSAVE,0);. No special coding is needed to handle these situations. Observe how, especially in the Display Properties control panel under Windows '95, the preview running inside the little preview monitor gets terminated and then restarted every single time the control panel regains focus. If you saver takes a long time to start up this will look ugly, and you should look for ways to speed up the execution of your saver. One important thing is to check that you saver does not require any DLLs to be rebased. (Read about rebasing in WIN32.HLP). If your saver has a slow animation of some sort, you might consider saving its current state in the registry so that, next time it is started, it can resume from where it left off. Be especially careful about any activities which might change the focus. If your saver pops up a top-level window on startup, this will mess up the focus: the control panel will regain focus, and your saver will be started again, and it will pop up another top-level window, and so on. This makes it very difficult for you to debug your preview mode. For debugging of the preview window you can use a utility called ScrPrev which runs its own preview window and is a little less temperamental.
|09 Feb 2006, 07:48
< Last Thread | Next Thread >
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.