Consistency change: all Windows API structure field names now match case-wise (some were forcibly exported in the past for historical reasons: I originally started package ui by trying to write a Windows API wrapper, but decided to ditch that and just use the Windows API directly from package ui). Also more TODOs.

This commit is contained in:
Pietro Gagliardi 2014-05-11 11:11:00 -04:00
parent d0ac56c0fc
commit 9ed8d9c816
7 changed files with 33 additions and 33 deletions

View File

@ -95,7 +95,7 @@ func paintArea(s *sysData) {
hscroll, vscroll := getScrollPos(s.hwnd) hscroll, vscroll := getScrollPos(s.hwnd)
cliprect := image.Rect(int(xrect.Left), int(xrect.Top), int(xrect.Right), int(xrect.Bottom)) cliprect := image.Rect(int(xrect.left), int(xrect.top), int(xrect.right), int(xrect.bottom))
cliprect = cliprect.Add(image.Pt(int(hscroll), int(vscroll))) // adjust by scroll position cliprect = cliprect.Add(image.Pt(int(hscroll), int(vscroll))) // adjust by scroll position
// make sure the cliprect doesn't fall outside the size of the Area // make sure the cliprect doesn't fall outside the size of the Area
cliprect = cliprect.Intersect(image.Rect(0, 0, s.areawidth, s.areaheight)) cliprect = cliprect.Intersect(image.Rect(0, 0, s.areawidth, s.areaheight))
@ -127,8 +127,8 @@ func paintArea(s *sysData) {
// thanks to David Heffernan in http://stackoverflow.com/questions/23033636/winapi-gdi-fillrectcolor-btnface-fills-with-strange-grid-like-brush-on-window // thanks to David Heffernan in http://stackoverflow.com/questions/23033636/winapi-gdi-fillrectcolor-btnface-fills-with-strange-grid-like-brush-on-window
r1, _, err = _createCompatibleBitmap.Call( r1, _, err = _createCompatibleBitmap.Call(
uintptr(hdc), uintptr(hdc),
uintptr(xrect.Right - xrect.Left), uintptr(xrect.right - xrect.left),
uintptr(xrect.Bottom - xrect.Top)) uintptr(xrect.bottom - xrect.top))
if r1 == 0 { // failure if r1 == 0 { // failure
panic(fmt.Errorf("error creating off-screen rendering bitmap: %v", err)) panic(fmt.Errorf("error creating off-screen rendering bitmap: %v", err))
} }
@ -141,10 +141,10 @@ func paintArea(s *sysData) {
} }
prevrbitmap := _HANDLE(r1) prevrbitmap := _HANDLE(r1)
rrect := _RECT{ rrect := _RECT{
Left: 0, left: 0,
Right: xrect.Right - xrect.Left, right: xrect.right - xrect.left,
Top: 0, top: 0,
Bottom: xrect.Bottom - xrect.Top, bottom: xrect.bottom - xrect.top,
} }
r1, _, err = _fillRect.Call( r1, _, err = _fillRect.Call(
uintptr(rdc), uintptr(rdc),
@ -230,10 +230,10 @@ func paintArea(s *sysData) {
// and finally we can just blit that into the window // and finally we can just blit that into the window
r1, _, err = _bitBlt.Call( r1, _, err = _bitBlt.Call(
uintptr(hdc), uintptr(hdc),
uintptr(xrect.Left), uintptr(xrect.left),
uintptr(xrect.Top), uintptr(xrect.top),
uintptr(xrect.Right - xrect.Left), uintptr(xrect.right - xrect.left),
uintptr(xrect.Bottom - xrect.Top), uintptr(xrect.bottom - xrect.top),
uintptr(rdc), uintptr(rdc),
uintptr(0), // from the rdc's origin uintptr(0), // from the rdc's origin
uintptr(0), uintptr(0),
@ -287,8 +287,8 @@ func getAreaControlSize(hwnd _HWND) (width int, height int) {
if r1 == 0 { // failure if r1 == 0 { // failure
panic(fmt.Errorf("error getting size of actual Area control: %v", err)) panic(fmt.Errorf("error getting size of actual Area control: %v", err))
} }
return int(rect.Right - rect.Left), return int(rect.right - rect.left),
int(rect.Bottom - rect.Top) int(rect.bottom - rect.top)
} }
func scrollArea(s *sysData, wparam _WPARAM, which uintptr) { func scrollArea(s *sysData, wparam _WPARAM, which uintptr) {

View File

@ -65,15 +65,15 @@ func (l _LPARAM) _Y() int32 {
} }
type _POINT struct { type _POINT struct {
X int32 x int32
Y int32 y int32
} }
type _RECT struct { type _RECT struct {
Left int32 left int32
Top int32 top int32
Right int32 right int32
Bottom int32 bottom int32
} }
// Predefined cursor resource IDs. // Predefined cursor resource IDs.

View File

@ -53,7 +53,7 @@ func stdWndProc(s *sysData) func(hwnd _HWND, uMsg uint32, wParam _WPARAM, lParam
panic("GetClientRect failed: " + err.Error()) panic("GetClientRect failed: " + err.Error())
} }
// top-left corner is (0,0) so no need for winheight // top-left corner is (0,0) so no need for winheight
s.doResize(int(r.Left), int(r.Top), int(r.Right), int(r.Bottom), 0) s.doResize(int(r.left), int(r.top), int(r.right), int(r.bottom), 0)
// TODO use the Defer movement functions here? // TODO use the Defer movement functions here?
} }
return 0 return 0

View File

@ -503,7 +503,7 @@ func (s *sysData) setWindowSize(width int, height int) error {
return fmt.Errorf("error getting upper-left of window for resize: %v", r.err) return fmt.Errorf("error getting upper-left of window for resize: %v", r.err)
} }
// 0 because (0,0) is top-left so no winheight // 0 because (0,0) is top-left so no winheight
err := s.setRect(int(rect.Left), int(rect.Top), width, height, 0) err := s.setRect(int(rect.left), int(rect.top), width, height, 0)
if err != nil { if err != nil {
return fmt.Errorf("error actually resizing window: %v", err) return fmt.Errorf("error actually resizing window: %v", err)
} }

View File

@ -56,5 +56,5 @@ super ultra important things:
other things: other things:
- on windows 7, progress bars seem to animate from 0 -> pos when you turn off marquee mode and set pos; see if that's documented or if I'm doing something wrong - on windows 7, progress bars seem to animate from 0 -> pos when you turn off marquee mode and set pos; see if that's documented or if I'm doing something wrong
- intentional: http://social.msdn.microsoft.com/Forums/en-US/61350dc7-6584-4c4e-91b0-69d642c03dae/progressbar-disable-smooth-animation http://stackoverflow.com/questions/2217688/windows-7-aero-theme-progress-bar-bug http://discuss.joelonsoftware.com/default.asp?dotnet.12.600456.2 http://stackoverflow.com/questions/22469876/progressbar-lag-when-setting-position-with-pbm-setpos http://stackoverflow.com/questions/6128287/tprogressbar-never-fills-up-all-the-way-seems-to-be-updating-too-fast - these links have workarounds but blah; more proof that progressbars were programmatically intended to be incremented in steps - intentional: http://social.msdn.microsoft.com/Forums/en-US/61350dc7-6584-4c4e-91b0-69d642c03dae/progressbar-disable-smooth-animation http://stackoverflow.com/questions/2217688/windows-7-aero-theme-progress-bar-bug http://discuss.joelonsoftware.com/default.asp?dotnet.12.600456.2 http://stackoverflow.com/questions/22469876/progressbar-lag-when-setting-position-with-pbm-setpos http://stackoverflow.com/questions/6128287/tprogressbar-never-fills-up-all-the-way-seems-to-be-updating-too-fast - these links have workarounds but blah; more proof that progressbars were programmatically intended to be incremented in steps
- clean up windows struct field names (holdover from when the intent was to make a wrapper lib first and then use it rather than using the windows API directly) - check all uses of RECT.right/.bottom in Windows that don't have an accompanying -RECT.left/.top to make sure they're correct
- make all widths and heights parameters in constructors in the same place (or drop the ones in Window entirely?) - make all widths and heights parameters in constructors in the same place (or drop the ones in Window entirely?)

View File

@ -102,12 +102,12 @@ var getMessageFail = -1 // because Go doesn't let me
func msgloop() { func msgloop() {
var msg struct { var msg struct {
Hwnd _HWND hwnd _HWND
Message uint32 message uint32
WParam _WPARAM wParam _WPARAM
LParam _LPARAM lParam _LPARAM
Time uint32 time uint32
Pt _POINT pt _POINT
} }
for { for {

View File

@ -288,11 +288,11 @@ const (
) )
type _MINMAXINFO struct { type _MINMAXINFO struct {
PtReserved _POINT ptReserved _POINT
PtMaxSize _POINT ptMaxSize _POINT
PtMaxPosition _POINT ptMaxPosition _POINT
PtMinTrackSize _POINT ptMinTrackSize _POINT
PtMaxTrackSize _POINT ptMaxTrackSize _POINT
} }
func (l _LPARAM) MINMAXINFO() *_MINMAXINFO { func (l _LPARAM) MINMAXINFO() *_MINMAXINFO {