二、Windows编程GDI—SYSMETS1.C窗口消息处理程序

SYSMETS1.C程序中的WndProc窗口消息处理程序处理三个消息：WM_CREATE、WM_PAINT和WM_DESTROY。WM_DESTROY消息的处理方法与第三章的HELLOWIN程序相同。

WM_CREATE消息是窗口消息处理程序接收到的第一个消息。在CreateWindow函数建立窗口时，Windows产生这个消息。在处理WM_CREATE消息时，SYSMETS1呼叫GetDC取得窗口的设备内容，并呼叫GetTextMetrics取得内定系统字体的文字大小。SYSMETS1将平均字符宽度保存在cxChar中，将字符的总高度（包括外部间距）保存在cyChar中。

SYSMETS1还将大写字母的平均宽度保存在静态变量cxCaps中。对于固定宽度的字体， cxCaps等于cxChar。对于可变宽度字体，cxCaps设定为cxChar乘以150％。对于可变宽度字体，TEXTMETRIC结构中的tmPitchAndFamily字段的低位为1，对于固定宽度字体，该值为0。 SYSMETS1使用这个位从cxChar计算cxCaps：

cxCaps = (tm.tmPitchAndFamily & 1 ? 3 : 2) * cxChar / 2 ;
        

SYSMETS1在处理WM_PAINT消息处理期间完成所有窗口建立工作。通常，窗口消息处理程序先呼叫BeginPaint取得设备内容句柄，然后用一道for叙述对SYSMETS.H中定义的sysmetrics结构的每一行进行循环。三列文字用三个TextOut函数显示，对于每一列，TextOut的第三个参数都设定为：

cyChar * i
        

这个参数指示了字符串顶端相对于显示区域顶部的图素位置。

第一条TextOut叙述在第一列显示了大写标识符。TextOut的第二个参数是0，这是说文字从显示区域的左边缘开始。文字的内容来自sysmetrics结构的szLabel字段。我使用Windows函数lstrlen来计算字符串的长度，它是TextOut需要的最后一个参数。

第二条TextOut叙述显示了对系统尺寸值的描述。这些描述存放在sysmetrics结构的szDesc字段中。在这种情况下，TextOut的第二个参数设定为：

22 * cxCaps
        

第一列显示的最长的大写标识符有20个字符，因此第二列必须在第一列文字开头向右20 × cxCaps处开始。我使用22，以在两列之间加一点多余的空间。

第三条TextOut叙述显示从GetSystemMetrics函数取得的数值。变宽字体使得格式化向右对齐的数值有些棘手。从0到9的数字具有相同的宽度，但是这个宽度比空格宽度大。数值可以比一个数字宽，所以不同的数值应该从不同的横向位置开始。

那么，如果我们指定字符串结束的图素位置，而不是指定字符串的开始位置，以此向右对齐数值，是否会容易一些呢？用SetTextAlign函数就可以做到这一点。在SYSMETS1呼叫：

SetTextAlign (hdc, TA_RIGHT | TA_TOP) ;
        

之后，传给后续TextOut函数的坐标将指定字符串的右上角，而不是左上角。

显示列数的TextOut函数的第二个参数设定为：

22 * cxCaps + 40 * cxChar
        

值40*cxChar包含了第二列的宽度和第三列的宽度。在TextOut函数之后，另一个对SetTextAlign的呼叫将对齐方式设定回普通方式，以进行下次循环。

空间不够

在SYSMETS1程序中存在着一个很难处理的问题：除非您有一个大屏幕跟高分辨率的显示卡，否则就无法看到系统尺度列表的最后几行。如果窗口太窄，甚至根本看不到值。

SYSMETS1不知道这个问题。否则我们就会显示一个消息框说「抱歉！」程序甚至不知道它的显示区域有多大，它从窗口顶部开始输出文字，并仰赖Windows裁剪超出显示区域底部的内容。

显然，这很不理想。为了解决这个问题，我们的第一个任务是确定程序在显示区域内能输出多少内容。

显示区域的大小

如果您使用过现有的Windows应用程序，可能会发现窗口的尺寸变化极大。窗口最大化时（假定窗口只有标题列并且没有菜单），显示区域几乎占据了整个屏幕。这一最大化了的显示区域的尺寸可以通过以SM_CXFULLSCREEN和SM_CYFULLSCREEN为参数呼叫GetSystemMetrics来获得。窗口的最小尺寸可以很小，有时甚至不存在，更不用说显示区域了。

在最近一章，我们使用GetClientRect函数来取得显示区域的大小。使用这个函数没有什么不好，但是在您每次要使用信息时就去呼叫它一遍是没有效率的。确定窗口显示区域大小的更好方法是在窗口消息处理程序中处理WM_SIZE消息。在窗口大小改变时，Windows给窗口消息处理程序发送一个WM_SIZE消息。传给窗口消息处理程序的lParam参数的低字组中包含显示区域的宽度，高字组中包含显示区域的高度。要保存这些尺寸，需要在窗口消息处理程序中定义两个静态变量：

static int cxClient, cyClient ;
        

与cxChar和cyChar相似，这两个变量在窗口消息处理程序内定义为静态变量，因为在以后处理其它消息时会用到它们。处理WM_SIZE的方法如下：

caseWM_SIZE:
        
   cxClient = LOWORD (lParam) ;
        
   cyClient = HIWORD (lParam) ;
        
   return 0 ;
        

实际上您会在每个Windows程序中看到类似的程序代码。LOWORD和HIWORD宏在Windows表头文件WINDEF.H中定义。这些宏的定义看起来像这样：

#define LOWORD(l) ((WORD)(l))
        
#define HIWORD(l) ((WORD)(((DWORD)(l) >> 16) & 0xFFFF))
        

这两个宏传回WORD值（16位的无正负号整数，范围从0到0xFFFF）。一般，将这些值保存在32位有号整数中。这就不会牵扯到任何转换问题，并使得这些值在以后需要的任何计算中易于使用。

在许多Windows程序中，WM_SIZE消息必然跟着一个WM_PAINT消息。为什么呢？因为在我们定义窗口类别时指定窗口类别样式为：

CS_HREDRAW | CS_VREDRAW
        

这种窗口类别样式告诉Windows，如果水平或者垂直大小发生改变， 则强制更新显示区域。

用如下公式计算可以在显示区域内显示的文字的总行数：

cyClient / cyChar
        

如果显示区域的高度太小以至无法显示一个完整的字符，这个公式的结果可以为0。类似地，在显示区域的水平方向可以显示的小写字符的近似数目为：

cxClient / cxChar
        

如果在处理WM_CREATE消息处理期间取得cxChar和cyChar，则不用担心在这两个计算公式中会出现被0除的情况。在WinMain呼叫CreateWindow时，窗口消息处理程序接收一个WM_CREATE消息。在WinMain呼叫ShowWindow之后接收到第一个WM_CREATE消息，此时cxChar和cyChar已经被赋予正的非零值了。

如果显示区域的大小不足以容纳所有的内容，那么，知道窗口显示区域的大小只是为使用者提供了在显示区域内卷动文字的第一步。如果您对其他有类似需求的Windows应用程序很熟悉，就很可能知道，这种情况下，我们需要使用「滚动条」。