处理功能键
功能键的问题在于，用户界面并非固定的，用户功能键的选择将使屏幕画面处于不同的显示状态下。例如，主画面如图1：
|
图1 主画面 |
当用户在设置XX上按下Enter键之后，画面就切换到了设置XX的界面，如图2：
|
图2 切换到设置XX画面 |
程序如何判断用户处于哪一画面，并在该画面的程序状态下调用对应的功能键处理函数，而且保证良好的结构，是一个值得思考的问题。
让我们来看看WIN32编程中用到的"窗口"概念，当消息（message）被发送给不同窗口的时候，该窗口的消息处理函数（是一个callback函数）最终被调用，而在该窗口的消息处理函数中，又根据消息的类型调用了该窗口中的对应处理函数。通过这种方式，WIN32有效的组织了不同的窗口，并处理不同窗口情况下的消息。
我们从中学习到的就是：
（1）将不同的画面类比为WIN32中不同的窗口，将窗口中的各种元素（菜单、按钮等）包含在窗口之中；
（2）给各个画面提供一个功能键"消息"处理函数，该函数接收按键信息为参数；
（3）在各画面的功能键"消息"处理函数中，判断按键类型和当前焦点元素，并调用对应元素的按键处理函数。
| /* 将窗口元素、消息处理函数封装在窗口中 */ struct windows { BYTE currentFocus; ELEMENT element[ELEMENT_NUM]; void (*messageFun) (BYTE keyValue); … }; /* 消息处理函数 */ void messageFunction(BYTE keyValue) { BYTE i = 0; /* 获得焦点元素 */ while ( (element [i].ID!= currentFocus)&& (i < ELEMENT_NUM) ) { i++; } /* "消息映射" */ if(i < ELEMENT_NUM) { switch(keyValue) { case OK: element[i].OnOk(); break; … } } } |
在窗口的消息处理函数中调用相应元素按键函数的过程类似于"消息映射"，这是我们从WIN32编程中学习到的。编程到了一个境界，很多东西都是相通的了。其它地方的思想可以拿过来为我所用，是为编程中的"拿来主义"。
在这个例子中，如果我们还想玩得更大一点，我们可以借鉴MFC中处理MESSAGE_MAP的方法，我们也可以学习MFC定义几个精妙的宏来实现"消息映射"。
。
