[RESOLVED] Laptop "Lid Close Test"

Hey guys,

I've been working on some software that tests the operational integrity of a notebook by testing individual hardware components.

So far, everything's working well. But my manager wants me to create a test that forces our testers to close the lid of the notebook.

I've managed to create a test, but it relies on the notebook going to sleep when the lid is closed and is not very reliable.

Ideally, I'd like to close the lid and have the power setting set to "Do Nothing" when the lid is closed. But all the research I've done, has turn up with nothing. I've even reached out to specialist sites like ExpertsExchange and I've even reached out to ATI to see if they had an API that would identify this on their video cards. I saw another guy trying to do something similar on VBF. In fact, the method he posted is what I'm using right now, but like I mentioned, it's not a viable method. I've seen many different posts on this, but no one's been able to come up with a method.

But! I've seen this before. I've seen software that can detect it, but I'm unable to get my hands on it.

So I was wondering if anyone knew of any third party software that would allow me to accomplish this.

Any ideas, guys?

Is the lid to be closed while to laptop in powered on? It would be cool if there was a machanism for closing the lid automatically.

Quote:

---

Originally Posted by Nightwalker83

Is the lid to be closed while to laptop in powered on? It would be cool if there was a machanism for closing the lid automatically.

---

Yes, the laptop will be on and the lid will be closed. A mechanism like that would be cool, but not really viable. Ha :p

ACPI will provide the status of the lid. I believe the actual event is some type of power button event. In Windows, I suspect the way to query the status is to use WMI, but — as you've doubtless already discovered — documentation is thin on the ground...
In Linux, you could make use of acpid.

A bit more time Googling led me to this MSDN forum thread:
http://social.msdn.microsoft.com/For...-016b57211b3a/

In short: You need to call RegisterPowerSettingNotification to receive the power state messages. Pass a window handle for the first parameter and DEVICE_NOTIFY_WINDOW_HANDLE (0) for the third. The second parameter is a GUID structure (use System.GUID in .NET) representing GUID_LIDSWITCH_STATE_CHANGE:

0xBA3E0F4D, 0xB817, 0x4094, 0xA2, 0xD1, 0xD5, 0x63, 0x79, 0xE6, 0xA0, 0xF3

The type of message that you need to trap is WM_POWERBROADCAST (0x218).
The event type (wParam) is PBT_POWERSETTINGCHANGE (0x8013). Use an overriden WndProc to trap the message.

Here is some more information:
Trapping the WM_POWERBROADCAST Window Message

This all requires Windows Vista or later, by the way.

OK, that might work when the laptop is set to do something (go to sleep or hibernate or turn off or whatever) whenever the lid is closed. What do you do when the laptop is not supposed to do anything? Registering for the power state change notification won't help because there will be no change in the power state even with the lid closed.

How about adding jagged teeth to the lid and have a co-worker place his/her palm on the keyboard while the lid is being closed, and as soon as the worker screams he/she would be supposed to click a button which tells you the lid is being closed?

On a (little) more serious note, is there a Lid_Closed() event triggered by any of the APIs?

The choice of name is confusing. The opening/closing of the lid is an ACPI "power button" event, even though it doesn't necessarily cause the power state to change. I think the notification should still happen, though I haven't tested it.

Quote:

---

Originally Posted by penagate

The choice of name is confusing. The opening/closing of the lid is an ACPI "power button" event, even though it doesn't necessarily cause the power state to change. I think the notification should still happen, though I haven't tested it.

---

I came across some of that information before, but not so much detail. I'll gvie it a try today and see what I come up with. It does sound like it might work though and I'm hopeful.

I've been at this for a couple of weeks now and it's pretty important, so I'm keeping my fingers crossed.

Quote:

---

Originally Posted by penagate

A bit more time Googling led me to this MSDN forum thread:
http://social.msdn.microsoft.com/For...-016b57211b3a/

In short: You need to call RegisterPowerSettingNotification to receive the power state messages. Pass a window handle for the first parameter and DEVICE_NOTIFY_WINDOW_HANDLE (0) for the third. The second parameter is a GUID structure (use System.GUID in .NET) representing GUID_LIDSWITCH_STATE_CHANGE:

0xBA3E0F4D, 0xB817, 0x4094, 0xA2, 0xD1, 0xD5, 0x63, 0x79, 0xE6, 0xA0, 0xF3

The type (wParam) of the window message you want is PBT_POWERSTATECHANGE (0x8013). Use an overriden WndProc to trap the message.

Here is some more information:
Trapping the WM_POWERBROADCAST Window Message

This all requires Windows Vista or later, by the way.

---

I was reading up on the information in this link that you provided and noticed there was a sample application. So I checked it out, but all of that code came to the same results I did with just the WindProc event.

So I looked through the code to see if it was as you described. I thought that if you had mentioned something he hadn't done, there was still hope.

And it turns out there might still be.

In his app, he's being notified of GUID_ACDC_POWER_SOURCE, GUID_BATTERY_PERCENTAGE_REMAINING, GUID_MONITOR_POWER_ON, and even GUID_POWERSCHEME_PERSONALITY. But not GUID_LIDSWITCH_STATE_CHANGE. Which I'm hoping is good news. So I'll try and work with that.

penagate, are you sure the message I need to trap is PBT_POWERSTATECHANGE? I wrote the code as you described, and unless I messed something up, it isn't working. But... I know you weren't 100% on if this would work. But, I'll post this in the VB.NET forum since this seems more focused on that now.

VB.NET Code:

Const PBT_POWERSTATECHANGE As Integer = &H8013
    Const DEVICE_NOTIFY_WINDOW_HANDLE As Integer = &H0
    Public Shared GUID_LIDSWITCH_STATE_CHANGE As New Guid(&HBA3E0F4DUI, &HB817, &H4094, &HA2, &HD1, &HD5, &H63, &H79, &HE6, &HA0, &HF3)
 
    Protected Overrides Sub WndProc(ByRef msg As System.Windows.Forms.Message)
        If msg.Msg = PBT_POWERSTATECHANGE Then
            MessageBox.Show("success?")
        End If
        MyBase.WndProc(msg)
    End Sub
 
    <DllImport("User32", EntryPoint:="RegisterPowerSettingNotification", CallingConvention:=CallingConvention.StdCall)> _
    Public Shared Function RegisterPowerSettingNotification(ByVal hRecipient As IntPtr, ByRef PowerSettingGuid As Guid, ByVal Flags As Int32) As IntPtr
    End Function
 
    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        RegisterPowerSettingNotification(Me.Handle, GUID_MAX_POWER_SAVINGS, DEVICE_NOTIFY_WINDOW_HANDLE)
    End Sub

I've got some great news! Another guy at work helped me figure this out.

So the issue was the message that I'm trapping. I guess PBT_POWERSTATECHANGE just wasn't the right one.

I'm not sure of the names of the correct ones, but we were sort of able to figure it out. The register API has to be used, but when wrote the msg from the WndProc method to the output window when debugging and found that either an integer of 536 or 537 is caught when the lid is closed.

So I'll need to do some finessing, but I should be able to get this to work just fine.

Sorry, my explanation was very poor. PBT_POWERSTATECHANGE is the wParam value, not the message type. The message type is WM_POWERBROADCAST, which is 0x218 (536) as you found out. The wParam is the sub-type of the message, in this case the type of power event.

Quote:

---

Originally Posted by penagate

Sorry, my explanation was very poor. PBT_POWERSTATECHANGE is the wParam value, not the message type. The message type is WM_POWERBROADCAST, which is 0x218 (536) as you found out. The wParam is the sub-type of the message, in this case the type of power event.

---

Oh. I see. I may not have read that as well, either.

But now I'm a little confused. If I trap the WM_POWERBROADCAST message, how do I utilize PBT_POWERSTATECHANGE?

Are you saying that if the WM_POWERBROADCAST message is sent, I should then do something with PBT_POWERSTATECHANGE?

It should be the case that msg.Msg = WM_POWERBROADCAST and msg.WParam = PBT_POWERSTATECHANGE.

Actually, the name of the constant is PBT_POWERSETTINGCHANGE, not PBT_POWERSTATECHANGE. Not sure where I got that one from.

Quote:

---

Originally Posted by penagate

It should be the case that msg.Msg = WM_POWERBROADCAST and msg.WParam = PBT_POWERSTATECHANGE.

---

Ah, yes. The wparam of the message. Right. That makes sense now.

I just tried it out and it works perfectly and even better than what I was using before. Thanks again, penagate. I've been at this for quite some time and I'm glad I've finally been able to get this to work.

Glad you sorted it. Sorry for confusing you before.