post hibernate situation

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

My application has no 'normal' monitor to speak of. It does write output
through a Titling board to a NTSC display. Writing to the Titling board
involves sending commands to position strings, etc.

I want my operator to be able to hibernate (I'll give him a menu choice
which will send an 'xpepm -hibernate' command. I then want the operator to
be able to power up and be at the same point in the application where he left
off. Right now, when I hibernate with the application running and then power
up, the program resumes running, but because if Titling board was also reset,
the display doesn't have any data on it, and thus, the operator is not really
back to where he left off.

I have read other posts that talk about trapping a power event message.
However, my application is not Windows/MFC/event based - it is a basic
console app. Another post talked about comparing the current time to the
last time stored, but that is not as easy to do as one might think, since I
have EWF on, so the 'stored' time would have to go on a USB (removeable)
drive.

Is there some way to either a) know that I just resumed from a hibernate
state, or b) have it run an application upon resuming from a hibernated
state. I am familiar with building components if it can be done through such.
 
Hi Hanley. Even though your application is a Console app, is it written in
C++, C#, Visual Basic, or another language that can access and leverage
Windows APIs? You do not need to be running a GUI application based on MFC
or .NET Framework in order to access power management messages - your app
simply needs to be able to handle Windows messages, which are provided by
the Win32 API.

Specifically, you will want to look into handling the WM_POWERBROADCAST
message, which the system sends out whenever a power-management event
occurs. A parameter supplied with the message indicates what the specific
event is (such as querying for suspension, suspending, resuming, etc.)

Check out this article and its related articles on MSDN:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/power/base/wm_powerbroadcast.asp .
This should help. =)

--
Matt Kellner ([email protected])
SDET, Windows Embedded Group

This posting is provided "AS IS" with no warranties, and confers no rights.
===============================
 
Matt,

Here is the part I am missing. I looked at your link and the function call
requires a HWND as its first parameter. I don't have any HWND because I
don't have any windows. I'm just a console app. Or are you saying I should
change my application to have windows so that I can make this function call?
I've written it in VC++. I'm familiar with MFC/Windows programming, but
don't know how to use windows when I don't have a video attached. On top of
that, I'm trying to keep my application small/and with as little complexity
as possible, and am afraid opening the Windows pandora box here. But if
windows is what I need, point me as to how.
 
Matt,

I'm further along now, but still not working. I found an article that
describes how to add windows to a console application. It starts a thread
which creates a dialog box and then sits in a while loop processing messages
looking for messages of interest. When I do this in my application, it
doesn't catch any WM_POWERBROADCAST messages. It catches a lot of WM_PAINT
and other types, but when I hibernate/resume it doesn't catch the ones I
need. Now, I know those messages are being sent because I have run SPY ( a
Visual C++ tool) which allows me to see all the message sent to a window and
that program shows the mssages sent. Is there a trick to catching the
WM_POWERBROADCAST messages?
 
I got it working. For some reason, doing a peek into the message queue
didn't work, but setting up a dialogproc and then checking for it there did.
If anyone has any thoughts on why, I'd be interested in knowing. Only thing
I found related to whether the WM_POWERBROADCAST message was sent or posted
(apparently there is some difference)
 
This is most likely because the window's DefWindowProc (the default message
handler for the dialog) was filtering out the power-management messages
before they got to the message queue. By defining your own WindowProc, you
break in to the message queue before the default handler can process them,
thus giving yourself access to the entire range of messages available.

I'm glad to see you got it working! I was unaware of the difficulties in
handling Windows Messages from a console app - my apologies for that.
However, your solution looks like a good one - thanks for keeping us
informed as to your progress. =)

--
Matt Kellner ([email protected])
SDET, Windows Embedded Group

This posting is provided "AS IS" with no warranties, and confers no rights.
===============================
 
Back
Top