Windows represents colors as 32-bit numbers, of which eight bits each correspond to the red, green, and blue intensity. That is, the 'red' parameter ranges from 0 for no red up to 255 for as much red as possible, and likewise for 'green' and 'blue'. RGB is a macro that packs the three byte-sized numbers into a 32-bit number (the high eight bits are 'reserved').
These color-representing integers are treated as a type called COLORREF, where COLORREF is defined in the windows.h file to mean unsigned long. If you know 0 to 255 intensities r, g, and b of red, green and blue that you want, then you can use the Windows macro RGB to create a COLORREF :
COLORREF col = RGB(r,g,b);
The order of the bytes from left to right is reserved, blue, green, red. The high, reserved byte is usually set to 0, although when you use special Windows color palettes (as is necessary when in 256 color mode), you may put something else into the reserved byte, such as a flag indicating that the remaining three bytes contain an index into a special Windows palette object.
There are few things to say about Windows rectangles. The CRect class discussed below is actually is a child of an older kind of Windows structure called a RECT.
A window's 'client rectangle' is the region, exclusive of the caption bar and frame, into which the user can write things. The CWnd::GetClientRect(CRect box) function puts the coordinates of the client rectangle into the CRect box object that you pass to the function as argument.
The coordinate system used by GetClientRect is said to be in terms of 'logical units' and by default the logical units are pixel units, with the upper left-hand corner of the Windows client rectangle being treated as the origin (0,0). The absolute screen pixel coordinates are not used here, although they are used by some other Windows functions.
When using the default logical pixel coordinates, a window measures the y-axis in the downward direction. So moving down the screen corresponds to increasing the value of y. Thus, the value of bottom is normally larger than that of top, unless the rectangle happens to have been deliberately or accidentally defined in a 'upside down' manner.
When working with Windows rectangles, we think of the (left, top ) or TopLeft () corner as being 'inside' the rectangle, with the (right, bottom ) or BottomRight () corner being 'outside the rectangle.' In other words, a rectangle can be thought of as having a closed boundary along its top and left edges, and an open boundary along its right and bottom edges. This is analogous to the calculus notion of a half-open interval like [0,1), which includes the left endpoint but not the right endpoint. In other words, the last lower-right-hand point actually inside the rectangle is (right-1, bottom-1).
Since the origin is in fact the (left, top) position of the client rectangle, after a call to GetClientRect(rect), rect.left is 0, rect.top is 0, rect.right is the width of the client area in pixels, and rect.bottom is the height of the client area in pixels. You can see that this is correct because, for instance, the pixels inside the rectangle have x-coordinates ranging from 0 up to rect.right ? 1, which makes for rect.right pixels in all.