post-hibernation wakeup requires mouse/keypress

[hanleyh1]

After receiveing a WM_POWERBROADCAST message while resuming from hibernation,
I call methods to redraw some screen areas (my screen in this case is an NTSC
screen with a Titling board writing to it). However, none of the screen
updates will take place until I either move the mouse or press a key on the
keyboard. Our system will ship without a mouse, and it is not intuitive for
the operator to have to press a key to begin things. Is there a way to cause
a keypress/mouse move to be received by the 'system' I've already tried
SendMessage(), but that did not work.

[KM]

Did you try keybd_event, PostKeybdMessage and/or mouse_event APIs.

--
=========
Regards,
KM

[hanleyh1]

I haven't for the following reasons. My earlier post was not entirely
accurate, in that I 'thought' I was receiving the WM_POWERBROADCAST event,
but in fact do not receive this event until AFTER a mouse move/keypress.

a) I know my program wakes up. I have a while loop in main that does a
printf every 5 seconds and when I resume from hibernation, I start seeing
these messages.

b) My sendmsg works. I put it in the while loop in main, and the thread
which listens for window events receives it (I have a dialogproc in that
thread).

c) however, that same dialogproc, which is used to receive the
WM_POWERBROADCAST messages, does not receive a WM_POWERBROADCAST message
until I either move the mouse or press a keyboard key. It is as though a
mousepress/keyboard key press 'releases' the WM_POWERBROADCAST message (who
is holding it up, or why, I have no idea)

I can try the keybd_event, PostKeybdMessage and/or mouse_event APIs, but
since my sendMessage is working, but not having the desired effect, I suspect
those will not work either.

[KM]

hanleyh1,

Is this a console app (I suspect so since you are using printf statements) ?

Does the problem appear there if you are switching to a GUI app?

Can you show us that "while" loop code? Specifically, are you doing PeekMessage there or GetMessage?

Is it only WM_POWERBROADCAST message which is giving you the trouble? Are you getting any other message in that loop after the
system resume?

=========
Regards,
KM

[hanleyh1]

1. Yes it is a console app. Although it does have a window, so that I can
trap the WM_POWERBROADCAST events. In the target system, there is not a
VGA monitor, but rather an NTSC monitor that is written to by a titling
board. So, I started out with a 'simple' console app, because there really
wasn't a need for windows in the application. And I guess I'd rather not
make it a full-blown window app, as, since there won't be windows on the
target system, there is no way to mouse between windows, etc.

In my thread which 'listens' for events to the window I created (a dialog
box), I have a loop that does a get message (followed by translate/dispatch).
However, the WM_POWERBROADCAST messages never make it into this queue.
Rather, I learned that I needed to set up a dialogproc which DOES get these
messages (both on the act of hibernating and also the act of resuming).

In my main thread, I am able to successfully (upon resume) send characters
that are received by the dialogproc. However, the WM_POWERBROADCAST messages
that *should* be received by this same dialogproc upon resume, are not
received until the mouse is moved or the keyboard is pressed. I don't know
if other messages are not getting through - WM_POWERBROADCAST is the only
ones I am checking for here. Following is some code from my main thread, and
then from the dialogproc:

// in main thread
::SendMessage(hWnd, WM_CHAR, VK_TAB, NULL); //works

// in dialogproc
INT_PTR CALLBACK DialogProc (HWND hwnd,UINT uMsg,WPARAM wParam,LPARAM lParam)
{
if (uMsg == WM_CHAR)
{
printf("dialogproc got the char\n");
}
else if (uMsg == WM_POWERBROADCAST ) // I don't get this one until
mousemove/keypress
{
if (wParam == PBT_APMRESUMEAUTOMATIC ||
wParam == PBT_APMRESUMECRITICAL ||
wParam == PBT_APMRESUMESUSPEND)
{
bresumedFromHibernate = true;
printf("got the resume\n");
}
}
return false;

[KM]

hanleyh1,

I didn't say you should only use GUI apps and not use console app. I was just trying to help you to debug the problem.
It would be interesting to know whether the console app is the root of the problem. Not seeing your entire code we can only guess
how exactly you are making calls to APIs.

Can you add more debug statements (printf in your case) to the WM_POWERBROADCAST handler? I wonder if you are getting PBT_APMSUSPEND
event in your app queue.

=========
Regards,
KM

[KM]

And forgot to ask:
- how precisely you are putting the system in hibernation?
- if you run Spy++ before the hibernation, on resume are you seeing the power broadcast being sent out in the system?

=========
Regards,
KM

"KM" <konstmor@nospam_yahoo.com> wrote in message news:u5XKB3FI...@TK2MSFTNGP11.phx.gbl...

[hanleyh1]

I found a solution. But first to answer your question - Spy reports that the
commands are being sent (both on the hibernation and on the resume). I'd
like to say that I don't *think* I was doing anything wrong. But here is
what I learned which led me to the solution.

In the writeup for PBT_APMRESUMEAUTOMATIC it says:

<<The PBT_APMRESUMEAUTOMATIC event is broadcast when the computer wakes up
automatically to handle an event. An application will not generally respond
unless it is handling the event, because the user is not present.>>

I wasn't sure what to make of that "will generally not respond unless it is
handling the event", since I *thought* I was handling it (by way of having a
dialogproc). But it made me suspicious enough to believe that 'the user is
not present' was a way of saying that the mouse wasn't moving or keys weren't
being pressed.

I then found under System Wakeup Events:

<<When the system wakes automatically, the system broadcasts the
PBT_APMRESUMEAUTOMATIC event to all applications. Because the user is not
present, most applications should do nothing. Event-handling applications,
such as fax servers, should handle their events. If you wish to determine
whether the system is in this state, call the IsSystemResumeAutomatic
function.>>

This led me to put the call in my main thread:

if ( IsSystemResumeAutomatic())
bresumedFromHibernation = true;

It turns out this will return true when the sysem is in that 'state'. I
can then redraw my screen to it's initial state (what this whole exercise was
for). Upon moving the mouse or pressing a key the WM_POWERBROADCAST messages
then arrive (I guess better late than never), which causes me to leave this
'state' (so the next time through my while loop in the main thread, I don't
call my redraw again).

At this point, I'm not even sure I needed to create the thread that creates
the dialog window - I think I could have done everything just off this
function call. After I get done writing this post, I'm going to remove the
thread that creates the window and retry.

BTW, I run my program on two computers. One is a desktop running Win XP and
it never exhibits the aforementioned problem - the dialogproc gets the
WM_POWERBROADCAST as soon as the hibernation file loads. The second is a SBC
running Win XP Embedded which is the target hardware and was exhibiting the
problem. So, maybe it is 'unique' to the hardware.

Thanks for all your help.

[KM]

hanleyh1,

That was the reason I asked you how exactly you're doing the hibernation.
I was intending to propose the power state check with CallNtPowerInformation API. I still recommend you to use this API instead of
the IsSystemResumeAutomatic since the latter is only for checking automatic resume state.

Basically the system wake-up latency is not guaranteed, because wake-up time is determined by the hardware design of the particular
computer.
You could try to set it to lowest though through RequestWakeupLatency API
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/power/base/requestwakeuplatency.asp).

What likely was happening in your case is that the system was in wakeup-pending state after resume until you move the mouse or press
a key on keyboard. The power broadcast message flow would show us more details on the timing on your target hardware and in your app
particular.

=========
Regards,
KM

[hanleyh1]

I was wrong again. Up until now, I had only run Spy on my desktop PC to
follow the command flow. On the SBC it is different in that:

a) I don't see any WM_POWERBROADCAST commands being sent to my window upon
the hibernation (xpepm -hibernate) (on my PC I believe I saw two.

b) On resume, nothing is in the Spy window until I move the mouse/press a
key, at which point I see APM_RESUMECRITICAL sent and received succeeded)
which again leads me to conclude that the WM_POWERBROADCAST is 'held up' in
some way (I'm basing this on the fact that other WM_ commands are trapped by
the dialogproc after resuming - the WM_CHAR command that I sent it). (on my
PC, I see WM_BROADCAST commands in the Spy window without needing to move the
mouse/press a key).

I tried setting the latency time, and while it succeeded, it had no impact
on the coming out of resume problem.

I looked at CallNtPowerInformation and am not sure how I would use that to
determine my situation.

regards,

Hanley

[KM]

hanleyh1,

Is your image Minlogon or Winlogon based?

If it is Minlogon, any chance you applied this QFE:
http://www.microsoft.com/downloads/details.aspx?familyid=03d2ebbb-5a04-447c-9c33-de44f1d2471b&displaylang=en ?

=========
Regards,
KM

[hanleyh1]

It is Winlogon based. Now, I don't know if this is relevant, but I've been
using the 'free' download WinXPe, SP2 thusfar, as my company hasn't purchased
the official tools yet. So, I don't have any QFEs loaded.