Move power event handling logic from ui/ to base/ on Windows

base/system_monitor/system_monitor_win.cc

 // Copyright (c) 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "base/system_monitor/system_monitor.h"
 
+#include "base/win/wrapped_window_proc.h"
+
 namespace base {
 
-void SystemMonitor::ProcessWmPowerBroadcastMessage(int event_id) {
+namespace {
+
+const wchar_t kWindowClassName[] = L"Base_PowerMessageWindow";
+
+}  // namespace
+
+// Function to query the system to see if it is currently running on
+// battery power.  Returns true if running on battery.
+bool SystemMonitor::IsBatteryPower() {
+  SYSTEM_POWER_STATUS status;
+  if (!GetSystemPowerStatus(&status)) {
+    DLOG_GETLASTERROR(ERROR) << "GetSystemPowerStatus failed";
+    return false;
+  }
+  return (status.ACLineStatus == 0);
+}
+
+SystemMonitor::PowerMessageWindow::PowerMessageWindow()
+    : instance_(NULL), message_hwnd_(NULL) {
+  WNDCLASSEX window_class;
+  base::win::InitializeWindowClass(
+      kWindowClassName,
+      &base::win::WrappedWindowProc<
+          SystemMonitor::PowerMessageWindow::WndProcThunk>,
+      0, 0, 0, NULL, NULL, NULL, NULL, NULL,
+      &window_class);
+  instance_ = window_class.hInstance;
+  ATOM clazz = RegisterClassEx(&window_class);
+  DCHECK(clazz);
+
+  message_hwnd_ = CreateWindow(kWindowClassName,
+                         0, 0, 0, 0, 0, 0, 0, 0, instance_, 0);

[cpu_(ooo_6.6-7.5), 2013/02/21 20:44:38]

the createwindow call is unnecessarily terse, use NULL for the name using 0 for
the style is WS_OVERLAPPED which implies title and border which is weird, how
about
WS_POPUP? does that still work?

In fact try WS_POPUP and WS_EX_NOACTIVATE for the 'ex style'
see if that works.

[Hongbo Min, 2013/02/22 06:55:43]

I am a bit confused by your concerns about the title and border. Since the size
of the window is not (0, 0), which should be invisible. Why do we care about its
appearance?

And the code I referenced is from content/browser/system_message_window_win.cc

[cpu_(ooo_6.6-7.5), 2013/02/23 18:00:55]

Because the right flags signal your intention. And we don't use 0 for NULL.

On top of that you get all the nonclient area messages, since you said you have
a full featured window.
Yeah, still wrong. No need to cargo cult that into other code.

[Hongbo Min, 2013/02/24 07:27:22]

cpu@, I did an experiment to verify the concerns you mentioned by writing a
small program using CreateWindow with different styles. Let me summarize the
findings to you.

1) The title and border won't be showed if ShowWindow is not called, regardless
of the window size and styles.

2) If the window size is (0, 0) and ShowWindow gets called, the title and border
become weird, as you said.

3) By use of WM_EX_NOACTIVATE ex style, the window won't be showed on the task
bar even if ShowWindow gets called.

4) By use of WM_POPUP, no title and border is showed if ShowWindow gets called.

5) All the nonclient area messages are received even if using WM_EX_NOACTIVATE
and WM_POPUP. I create two windows for testing, one is using WS_OVERLAPPEDWINDOW
(called A), the one is using WM_EX_NOACTIVATE and WM_POPUP (called B), according
to the output, the latter one could receive all nonclient area messages from the
former one, for example, if I resize the A window, B window can still receive
the nonclient area messages arose from resizing.

So if not calling ShowWindow on the hwnd, there is no obvious benefit from using
WM_EX_NOACTIVATE + WS_POPUP although it is a more cleaner and stricter way.

[vandebo (ex-Chrome), 2013/02/25 17:46:54]

I think Carlos would like you to do the clearer thing.

+  SetWindowLongPtr(message_hwnd_, GWLP_USERDATA,
+                   reinterpret_cast<LONG_PTR>(this));
+}
+
+SystemMonitor::PowerMessageWindow::~PowerMessageWindow() {
+  if (message_hwnd_)
+    DestroyWindow(message_hwnd_);
+}
+
+void SystemMonitor::PowerMessageWindow::ProcessWmPowerBroadcastMessage(
+    int event_id) {
   PowerEvent power_event;
   switch (event_id) {
     case PBT_APMPOWERSTATUSCHANGE:  // The power status changed.
-      power_event = POWER_STATE_EVENT;
+      power_event = SystemMonitor::POWER_STATE_EVENT;
       break;
     case PBT_APMRESUMEAUTOMATIC:  // Resume from suspend.
     //case PBT_APMRESUMESUSPEND:  // User-initiated resume from suspend.
                                   // We don't notify for this latter event
                                   // because if it occurs it is always sent as a
                                   // second event after PBT_APMRESUMEAUTOMATIC.
-      power_event = RESUME_EVENT;
+      power_event = SystemMonitor::RESUME_EVENT;
       break;
     case PBT_APMSUSPEND:  // System has been suspended.
-      power_event = SUSPEND_EVENT;
+      power_event = SystemMonitor::SUSPEND_EVENT;
       break;
     default:
       return;
 
     // Other Power Events:
     // PBT_APMBATTERYLOW - removed in Vista.
     // PBT_APMOEMEVENT - removed in Vista.
     // PBT_APMQUERYSUSPEND - removed in Vista.
     // PBT_APMQUERYSUSPENDFAILED - removed in Vista.
     // PBT_APMRESUMECRITICAL - removed in Vista.
     // PBT_POWERSETTINGCHANGE - user changed the power settings.
   }
-  ProcessPowerMessage(power_event);
+  SystemMonitor::Get()->ProcessPowerMessage(power_event);
 }
 
-// Function to query the system to see if it is currently running on
-// battery power.  Returns true if running on battery.
-bool SystemMonitor::IsBatteryPower() {
-  SYSTEM_POWER_STATUS status;
-  if (!GetSystemPowerStatus(&status)) {
-    DLOG_GETLASTERROR(ERROR) << "GetSystemPowerStatus failed";
-    return false;
+LRESULT CALLBACK SystemMonitor::PowerMessageWindow::WndProc(
+    HWND hwnd, UINT message, WPARAM wparam, LPARAM lparam) {
+  switch (message) {
+    case WM_POWERBROADCAST: {
+      DWORD power_event = static_cast<DWORD>(message);
+      ProcessWmPowerBroadcastMessage(power_event);
+      return TRUE;
+    }
+    default:
+      break;
   }
-  return (status.ACLineStatus == 0);
+  return ::DefWindowProc(hwnd, message, wparam, lparam);
+}
+
+// static
+LRESULT CALLBACK SystemMonitor::PowerMessageWindow::WndProcThunk(
+    HWND hwnd, UINT message, WPARAM wparam, LPARAM lparam) {
+  SystemMonitor::PowerMessageWindow* message_hwnd =
+      reinterpret_cast<SystemMonitor::PowerMessageWindow*>(
+          GetWindowLongPtr(hwnd, GWLP_USERDATA));

[cpu_(ooo_6.6-7.5), 2013/02/21 20:44:38]

hmmm danger danger

You can (and will) receive messages before line 43 is executed, you need to pass
those to defwindowproc

[vandebo (ex-Chrome), 2013/02/21 20:54:45]

Will message_hwnd be Null in that case?  If so, line 103 should catch that case,
right?

[Hongbo Min, 2013/02/22 06:55:43]

I agree with Steve.

[cpu_(ooo_6.6-7.5), 2013/02/23 18:00:55]

I agree too. I must have misread it.

+  if (message_hwnd)
+    return message_hwnd->WndProc(hwnd, message, wparam, lparam);
+  return ::DefWindowProc(hwnd, message, wparam, lparam);
 }
 
 }  // namespace base