Documented window switch clicks in Area and implemented them on Windows and Mac OS X.

area.go

@@ -80,6 +80,8 @@ type AreaHandler interface {
 // For example, on Windows, buttons 4 and 5 are mapped to what are internally referred to as "XBUTTON1" and "XBUTTON2", which often correspond to the dedicated back/forward navigation buttons on the sides of many mice.
 // The examples here are NOT a guarantee as to how many buttons maximum will be available on a given system.
 // (TODO find out if there's a way to query available button count)
+// 
+// If the user clicked on the Area to switch to the Window it is contained in from another window in the OS, the Area will receive a MouseEvent for that click.
 type MouseEvent struct {
 	// Pos is the position of the mouse in the Area at the time of the event.
 	Pos			image.Point

area_darwin.m

@@ -56,6 +56,12 @@ extern NSRect dummyRect;
 	return YES;
 }
 
+// this will have the Area receive a click that switches to the Window it is in from another one
+- (BOOL)acceptsFirstMouse:(NSEvent *)e
+{
+	return YES;
+}
+
 - (void)retrack
 {
 	trackingArea = [[NSTrackingArea alloc]

area_windows.go

@@ -643,8 +643,8 @@ func areaWndProc(hwnd _HWND, uMsg uint32, wParam _WPARAM, lParam _LPARAM) _LRESU
 		// (see http://www.catch22.net/tuts/custom-controls)
 		// don't bother checking SetFocus()'s error; see http://stackoverflow.com/questions/24073695/winapi-can-setfocus-return-null-without-an-error-because-thats-what-im-see/24074912#24074912
 		_setFocus.Call(uintptr(s.hwnd))
-//		return _MA_ACTIVATE		// TODO eat the click?
-		return defWindowProc(hwnd, uMsg, wParam, lParam)
+		// and don't eat the click, as we want to handle clicks that switch into Windows with Areas from other windows
+		return _MA_ACTIVATE
 	case _WM_MOUSEMOVE:
 		areaMouseEvent(s, 0, false, wParam, lParam)
 		return 0

todo.md

@@ -20,7 +20,7 @@ WINDOWS:
 
 UNIX:
 - double-check to make sure MouseEvent.Held[] is sorted on Unix after we figure out how to detect buttons above button 5
-- pin down whether or not a click event gets sent if this click changes from a different window to the one with the Area
+- figure out why I don't need to explicitly enable click on activate so I can document it
 - david wendt is telling me he's getting frequent crashes on his end with the GTK+ amd64 build...
 	TODO re-evaluate; I think I fixed them all ages ago now
 - when resizing a GTK+ window smaller than a certain size, the controls inside will start clipping in bizarre ways (the horizontal scrollbar in Area will disappear smoothly; etc.)

zconstants_windows_386.go

@@ -49,6 +49,7 @@ const _LB_GETTEXT = 393
 const _LB_GETTEXTLEN = 394
 const _LB_INSERTSTRING = 385
 const _LF_FACESIZE = 32
+const _MA_ACTIVATE = 1
 const _MB_APPLMODAL = 0
 const _MB_ICONERROR = 16
 const _MB_OK = 0

zconstants_windows_amd64.go

@@ -49,6 +49,7 @@ const _LB_GETTEXT = 393
 const _LB_GETTEXTLEN = 394
 const _LB_INSERTSTRING = 385
 const _LF_FACESIZE = 32
+const _MA_ACTIVATE = 1
 const _MB_APPLMODAL = 0
 const _MB_ICONERROR = 16
 const _MB_OK = 0