Fixed the major scrolling corruption on Windows: had to commit the scroll changes before we can get to them in our painting routine =P This doesn't fix ALL the issues; check the (now-updated) TODO.

area_windows.go

@@ -255,10 +255,7 @@ func scrollArea(s *sysData, wparam _WPARAM, which uintptr) {
 	if r1 == _ERROR {		// failure
 		panic(fmt.Errorf("error scrolling Area: %v", err))
 	}
-	r1, _, err = _updateWindow.Call(uintptr(s.hwnd))		// ...and redraw it
+	// ...but don't redraw the window yet; we need to apply our scroll changes
-	if r1 == 0 {		// failure
-		panic(fmt.Errorf("error updating Area after scrolling: %v", err))
-	}
 
 	// we actually have to commit the change back to the scrollbar; otherwise the scroll position will merely reset itself
 	si.cbSize = uint32(unsafe.Sizeof(si))
@@ -268,6 +265,13 @@ func scrollArea(s *sysData, wparam _WPARAM, which uintptr) {
 		uintptr(s.hwnd),
 		which,
 		uintptr(unsafe.Pointer(&si)))
+
+	// NOW redraw it
+	r1, _, err = _updateWindow.Call(uintptr(s.hwnd))
+	if r1 == 0 {		// failure
+		panic(fmt.Errorf("error updating Area after scrolling: %v", err))
+	}
+
 	// TODO in some cases wine will show a thumb one pixel away from the advance arrow button if going to the end; the values are correct though... weirdness in wine or something I never noticed about Windows?
 }
 

todo.md

@@ -84,7 +84,7 @@ super ultra important things:
 - the window background of a GTK+ window seems to be... off - I think it has to do with the GtkLayout
 - see update 18 March 2014 in README
 - resizing seems to be completely and totally broken in the Wayland backend
-- redrawing Areas on Windows seems to be flaky
+- redrawing Areas on Windows seems to be flaky: make the window small, scroll, then make it large again and watch the vertical corruption
 	- redrawing controls after a window resize on Windows seems to be flaky
 - make sure the first and last rows and columns of an Area are being drawn on Windows
 - clicking on Areas in GTK+ don't bring keyboard focus to them?