Re: post-hibernation wakeup requires mouse/keypress

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

>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" wrote:
>
>> 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
>>
>> >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" wrote:
>> >
>> >> 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@xxxxxxxxxxxxxxxx> wrote in message news:u5XKB3FIGHA.2320@xxxxxxxxxxxxxxxxxxxxxxx
>> >> > 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
>> >> >
>> >> >
>> >> >> 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" wrote:
>> >> >>
>> >> >>> 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
>> >> >>>
>> >> >>>
>> >> >>> >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" wrote:
>> >> >>> >
>> >> >>> >> Did you try keybd_event, PostKeybdMessage and/or mouse_event APIs.
>> >> >>> >>
>> >> >>> >> --
>> >> >>> >> =========
>> >> >>> >> Regards,
>> >> >>> >> KM
>> >> >>> >>
>> >> >>> >> > 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.
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>>
>>
>>


.

Loading