Fixed the standard window class focus behavior on Windows from the previous commit to work. Also updated the SetFocus() call in area_windows.go to boot and removed the relevant TODO after checking both wine and Windows XP work fine.

This commit is contained in:
Pietro Gagliardi 2014-06-06 01:49:23 -04:00
parent 00ec85dee6
commit 4856790299
5 changed files with 8 additions and 19 deletions

View File

@ -625,11 +625,9 @@ func areaWndProc(hwnd _HWND, uMsg uint32, wParam _WPARAM, lParam _LPARAM) _LRESU
// this happens on every mouse click (apparently), so DON'T reset the click counter, otherwise it will always be reset (not an issue, as MSDN says WM_ACTIVATE is sent alongside WM_MOUSEACTIVATE when necessary) // this happens on every mouse click (apparently), so DON'T reset the click counter, otherwise it will always be reset (not an issue, as MSDN says WM_ACTIVATE is sent alongside WM_MOUSEACTIVATE when necessary)
// transfer keyboard focus to our Area on an activating click // transfer keyboard focus to our Area on an activating click
// (see http://www.catch22.net/tuts/custom-controls) // (see http://www.catch22.net/tuts/custom-controls)
r1, _, err := _setFocus.Call(uintptr(s.hwnd)) // 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
if r1 == 0 { // failure _setFocus.Call(uintptr(s.hwnd))
panic(fmt.Errorf("error giving Area keyboard focus: %v", err)) // return _MA_ACTIVATE // TODO eat the click?
return _MA_ACTIVATE // TODO eat the click?
}
return defWindowProc(hwnd, uMsg, wParam, lParam) return defWindowProc(hwnd, uMsg, wParam, lParam)
case _WM_MOUSEMOVE: case _WM_MOUSEMOVE:
areaMouseEvent(s, 0, false, wParam, lParam) areaMouseEvent(s, 0, false, wParam, lParam)

View File

@ -92,15 +92,12 @@ func (s *sysData) handleFocus(wParam _WPARAM) {
old) old)
if r1 != 0 { if r1 != 0 {
s.lastfocus = _HWND(old) s.lastfocus = _HWND(old)
println("s",s.lastfocus)
} }
} }
} else { // focusing in } else { // focusing in
if s.lastfocus != _HWND(_NULL) { // if we have one if s.lastfocus != _HWND(_NULL) { // if we have one
r1, _, err := _setFocus.Call(uintptr(s.lastfocus)) // 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
if _HWND(r1) == _HWND(_NULL) { _setFocus.Call(uintptr(s.lastfocus))
panic(fmt.Errorf("error setting focus to previously focused window on reactivating Window: %v", err))
}
} }
} }
} }
@ -142,9 +139,9 @@ func stdWndProc(hwnd _HWND, uMsg uint32, wParam _WPARAM, lParam _LPARAM) _LRESUL
} }
} }
return 0 return 0
// case _WM_ACTIVATE: case _WM_ACTIVATE:
// s.handleFocus(wParam) s.handleFocus(wParam)
// return 0 return 0
case _WM_GETMINMAXINFO: case _WM_GETMINMAXINFO:
mm := lParam.MINMAXINFO() mm := lParam.MINMAXINFO()
// ... minimum size // ... minimum size

View File

@ -30,10 +30,6 @@ super ultra important things:
- on Windows, Shift+(num pad key) triggers the shifted key code when num lock is off; will need to reorder key code tests on all platforms to fix this - on Windows, Shift+(num pad key) triggers the shifted key code when num lock is off; will need to reorder key code tests on all platforms to fix this
- http://blogs.msdn.com/b/oldnewthing/archive/2004/09/06/226045.aspx - http://blogs.msdn.com/b/oldnewthing/archive/2004/09/06/226045.aspx
- related: make sure all keyboard checks are in the same order on all platforms - related: make sure all keyboard checks are in the same order on all platforms
- pressing global keycodes (including kwin's zoom in/out) when running the keyboard test in wine causes the Area to lose keyboard focus; this doesn't happen on the GTK+ version (fix the Windows version to behave like the GTK+ version)
- this also happens in real windows (press the windows key to open the start menu); there's something I'm not handling and I'm not sure what it is
- oh hey would you look at that http://blogs.msdn.com/b/oldnewthing/archive/2014/05/21/10527168.aspx how timely
- part 2 http://blogs.msdn.com/b/oldnewthing/archive/2014/05/22/10527522.aspx
- Message boxes that belong to agiven parent are still application-modal on all platforms except Mac OS X because the whole system waits... we'll need to use a channel for this, I guess :S - Message boxes that belong to agiven parent are still application-modal on all platforms except Mac OS X because the whole system waits... we'll need to use a channel for this, I guess :S
- [12:55] <myklgo> pietro10: I meant to mention: 1073): Gtk-WARNING **: Theme parsing error: gtk.css:72:20: Not using units is deprecated. Assuming 'px'. twice. - [12:55] <myklgo> pietro10: I meant to mention: 1073): Gtk-WARNING **: Theme parsing error: gtk.css:72:20: Not using units is deprecated. Assuming 'px'. twice.

View File

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

View File

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