At 10:03 AM 12/20/2005, Robert McGwier wrote:
Irrespective of the answer,  any time I blow the directX screen,  I must
exit the application to recover it.  I suspect the same it true here.  I
can switch to GDI+ and it will work and then switching back, or
standyon/on will NOT fix the problem.  That said,  I am with you.  It
does not seem to make operational sense to have a compute intensive
realtime process running if you are going to allow standby.  If you are,
exit PowerSDR.

Bob

I disagree.. the whole point of standby and/or hibernate is that you can close the laptop, push the button, or whatever, and preserve the state of the machine, so that you can come back to life very quickly.

The key is that a limited number of things have to be done to go into and out of standby mode (i.e. close the lid on the laptop or push the resume key).

Temporarily going qrt shouldn't take a hundred key strokes to shut down all the applications that might choke.


This is something that should not be "rocket science" to make work. At least, most all of my other windows applications seem to handle it ok, with the exception of a few communications applications (VPN and the like) that get confused when you go to sleep with one network configuration and wake up with another.

I will concede that microsoft doesn't make life easy for this (particularly with respect to graphics support), but at the very least, your application should be set up to receive (and appropriately process) the various Winlogon notification events.  On my computer, going into standby causes the "lock" event to occur, although, I confess, it might be incidental. You also get these when screen savers start and stop, and when the user shell (explorer.exe) starts and stops.  In order to truly detect power management stuff, you might need to have a device driver installed (device drivers get power management notifications)

Aha.. just found it in MSDN:
http://msdn.microsoft.com/library/default.asp?url="">

WM_POWERBROADCAST Messages

The system broadcasts a message to all applications and installable drivers whenever a power management event occurs or whenever an application calls the SetSystemPowerState function to suspend operation. The system broadcasts these events through the WM_POWERBROADCAST message, setting the wParam parameter to the appropriate power management event. For example, the PBT_APMPOWERSTATUSCHANGE event indicates a system power status change. You must ensure that your application responds to the WM_POWERBROADCAST message to properly stop activity when the system enters the sleeping state and to recover transparently when the system enters the working state. When the system enters the sleeping state, it closes network connections. The user can change the hardware configuration or power supply while the system is in the sleeping state.

The system broadcasts a PBT_APMQUERYSUSPEND event to request permission to suspend system operation. The system expects each application and driver to determine whether the requested event should occur and to return TRUE if it occurs, or return BROADCAST_QUERY_DENY otherwise. Any application or driver can deny the request and prevent the event from occurring.

The system broadcasts a PBT_APMSUSPEND event immediately before suspending operation. This gives applications and drivers one last chance to prepare for the event. In many cases, the system broadcasts these messages without requesting permission to do so. This happens, for example, if an application forces suspension with the SetSystemPowerState function.

The system broadcasts the PBT_APMQUERYSUSPENDFAILED event whenever a requested event is denied. These events notify applications and drivers to continue operation as usual.

The system broadcasts the PBT_APMRESUMESUSPEND or PBT_APMRESUMECRITICAL event when system operation has been restored. If an application received a PBT_APMSUSPEND event before the computer was suspended, it will receive the PBT_APMRESUMESUSPEND event. Otherwise, it will receive the PBT_APMRESUMECRITICAL event.



If the problem isn't in PowerSDR, but in the graphics drivers (always possible!):There's also a WinXP patch for Direct3D-based screen saver Hibernate/Standby error, which might be relevant.

And, WinXP SP2 has a whole raft of fixes pertaining to standby/hibernate, particularly with respect to device drivers, USB devices, etc.
http://support.microsoft.com/default.aspx?scid=kb;en-us;811113


More information on standby/hibernate that might be useful at:

http://www.microsoft.com/whdc/system/sysperf/fastboot/default.mspx
which talkes about bootvis.exe, used for diagnosing such things..



James Lux, P.E.
Spacecraft Radio Frequency Subsystems Group
Flight Communications Systems Section
Jet Propulsion Laboratory, Mail Stop 161-213
4800 Oak Grove Drive
Pasadena CA 91109
tel: (818)354-2075
fax: (818)393-6875

Reply via email to