diff options
| author | Pietro Gagliardi <[email protected]> | 2014-04-02 23:24:34 -0400 |
|---|---|---|
| committer | Pietro Gagliardi <[email protected]> | 2014-04-02 23:40:38 -0400 |
| commit | 773668c35b6aa1c0e9cd449fffcffeeea3d542a6 (patch) | |
| tree | 85dea05353b21f3576ea3b8ba104c687654e0c09 | |
| parent | a325e9e40478eb11d1559e1fbe2e9883a1f2b186 (diff) | |
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.
| -rw-r--r-- | area_windows.go | 12 | ||||
| -rw-r--r-- | todo.md | 2 |
2 files changed, 9 insertions, 5 deletions
diff --git a/area_windows.go b/area_windows.go index 6ba1b0c..5f69b6c 100644 --- a/area_windows.go +++ b/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 - if r1 == 0 { // failure - panic(fmt.Errorf("error updating Area after scrolling: %v", err)) - } + // ...but don't redraw the window yet; we need to apply our scroll changes // 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? } @@ -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? |
