// the bitmap has to be compatible with the window
// if we create a bitmap compatible with the DC we just created, it'll be monochrome
// thanks to David Heffernan in http://stackoverflow.com/questions/23033636/winapi-gdi-fillrectcolor-btnface-fills-with-strange-grid-like-brush-on-window
// this is all we need, but because this confused me at first, I will say the two pixels-per-meter fields are unused (see http://blogs.msdn.com/b/oldnewthing/archive/2013/05/15/10418646.aspx and page 581 of Charles Petzold's Programming Windows, Fifth Edition)
// now for the trouble: CreateDIBSection() allocates the memory for us...
ibitmap=CreateDIBSection(NULL,// Ninjifox does this, so do some wine tests (http://source.winehq.org/source/dlls/gdi32/tests/bitmap.c#L725, thanks vpovirk in irc.freenode.net/#winehackers) and even Raymond Chen (http://blogs.msdn.com/b/oldnewthing/archive/2006/11/16/1086835.aspx), so.
&bi,DIB_RGB_COLORS,&ppvBits,0,0);
if(ibitmap==NULL)
xpanic("error creating HBITMAP for image returned by AreaHandler.Paint()",GetLastError());
// now we have to do TWO MORE things before we can finally do alpha blending
// first, we need to load the bitmap memory, because Windows makes it for us
// the pixels are arranged in RGBA order, but GDI requires BGRA
// this turns out to be just ARGB in little endian; let's convert into this memory
// raymond chen says to just set the newpos to the SCROLLINFO nPos for this message; see http://blogs.msdn.com/b/oldnewthing/archive/2003/07/31/54601.aspx and http://blogs.msdn.com/b/oldnewthing/archive/2003/08/05/54602.aspx
// do nothing here; newpos already has nPos
break;
caseSB_THUMBTRACK:
newpos=(LONG)si.nTrackPos;
}
// otherwise just keep the current position (that's what MSDN example code says, anyway)
// make sure we're not out of range
if(newpos<0)
newpos=0;
if(newpos>(maxsize-pagesize))
newpos=maxsize-pagesize;
// this would be where we would put a check to not scroll if the scroll position changed, but see the note about SB_THUMBPOSITION above: Raymond Chen's code always does the scrolling anyway in this case
// these four change what is scrolled and record info about the scroll; we're scrolling the whole client area and don't care about the returned information here
// the trick is we want a page to be the width/height of the visible area
// so the scroll range would go from [0..image_dimension - control_dimension]
// but judging from the sample code on MSDN, we don't need to do this; the scrollbar will do it for us
// we DO need to handle it when scrolling, though, since the thumb can only go up to this upper limit
// have to do horizontal and vertical separately
ZeroMemory(&si,sizeof(SCROLLINFO));
si.cbSize=sizeof(SCROLLINFO);
si.fMask=SIF_RANGE|SIF_PAGE;
si.nMin=0;
si.nMax=(int)(areaWidthLONG(data)-1);// the max point is inclusive, so we have to pass in the last valid value, not the first invalid one (see http://blogs.msdn.com/b/oldnewthing/archive/2003/07/31/54601.aspx); if we don't, we get weird things like the scrollbar sometimes showing one extra scroll position at the end that you can never scroll to
si.nPage=(UINT)cwid;
SetScrollInfo(hwnd,SB_HORZ,&si,TRUE);// redraw the scroll bar
// MSDN sample code does this a second time; let's do it too to be safe
/* act as if we're not ready yet, even during WM_NCCREATE (nothing important to the switch statement below happens here anyway) */
returnDefWindowProcW(hwnd,uMsg,wParam,lParam);
}
switch(uMsg){
caseWM_PAINT:
paintArea(hwnd,data);
return0;
caseWM_ERASEBKGND:
// don't draw a background; we'll do so when painting
// this is to make things flicker-free; see http://msdn.microsoft.com/en-us/library/ms969905.aspx
return1;
caseWM_HSCROLL:
scrollArea(hwnd,data,wParam,SB_HORZ);
return0;
caseWM_VSCROLL:
scrollArea(hwnd,data,wParam,SB_VERT);
return0;
caseWM_SIZE:
adjustAreaScrollbars(hwnd,data);
return0;
caseWM_ACTIVATE:
// don't keep the double-click timer running if the user switched programs in between clicks
areaResetClickCounter(data);
return0;
caseWM_MOUSEACTIVATE:
// 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
// (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(hwnd);
// and don't eat the click, as we want to handle clicks that switch into Windows with Areas from other windows
