当头文件中声明了一个函数，但是在相应的源文件中却没有对该函数进行定义，则会出现为“解决的外部符号”（unresolved external symbol ）错误。另外，当一个函数调用了外部的一个库文件中的函数，但是在当前project的properties中并没有将所依赖的（dependent）库文件包含进来时，也会出现这种错误。

       综上，当一个solution在linking时找不到所涉及到的函数的定义时就会出现“unresolved external symbol ”错误。

      例如，下面是调用rapi的库文件rapi.lib中的函数时，由于没有将rapi.lib包含进来而导致的链接错误。

1>Linking...
WMFileSync.obj : error LNK2019: unresolved external symbol _CeFindClose@4 referenced in function "public: virtual long __stdcall CWMFileSync::IsFileExists(wchar_t *)" (?IsFileExists@CWMFileSync@@UAGJPA_W@Z)

       【解决方案】

       1. Project -> ** Properties... -> Configuration Properties -> Linker -> Input -> Additional Dependencies -> rapi.lib

另外，在此之前，还需添加rapi库的相应目录：Tools -> Options -> Projects and Solutions -> VC++ Directories -> Show Directories for -> 在Include files中添加C:\Program Files\Matrox Imaging\rapi\Include 以及 Tools -> Options -> Projects and Solutions -> VC++ Directories -> Show Directories for -> 在Library files中添加C:\Program Files\Matrox Imaging\rapi\LIB。添加目录的目的是为了使VC在调用相应库文件时不必总是使用绝对地址，VC可以通过文件名在所包含的目录中进行搜索。这样，前面的rapi.lib就不必使用绝对地址了。

       【缺点】可移植性差，如果将原工程中的源文件和头文件中的内容copy下来重新建立该工程时（例如：在电子书或网络上找到的程序），仍需自己在工程中添加目录及所需的库文件。

       2. 在程序前加入#pragma commet(lib, "rapi.lib")也可以达到相同的效果。

PostMessage将消息WM_QUIT发送到消息队列中,由于PostMessage的立即返回(即结束)就执行下一句语句结束整个程序,消息还挂在消息队列中未处理故出错!!

在此，我个人认为：CString封装得确实很完美，它有许多优点，如“容易使用 ，功能强，动态分配内存，大量进行拷贝时它很能节省内存资源并且执行效率高，与标准Ｃ完全兼容，同时支持多字节与宽字节，由于有异常机制所以使用它安全方便” 其实，使用过程中之所以容易出错，那是因为我们对它了解得还不够，特别是它的实现机制。因为我们中的大多数人，在工作中并不那么爱深入地去看关于它的文档，何况它还是英文的。

由于前几天我在工作中遇到了一个本不是问题但却特别棘手、特别难解决而且莫名惊诧的问题。好来最后发现是由于CString引发的。所以没办法，我把整个CString的实现全部看了一遍，才慌然大悟，并彻底弄清了问题的原因(这个问题，我已在csdn上开贴)。在此，我想把我的一些关于CString的知识总结一番，以供他（她）人借鉴，也许其中有我理解上的错误，望发现者能通知我，不胜感谢。

1． CString实现的机制.

CString是通过“引用”来管理串的，“引用”这个词我相信大家并不陌生，象Window内核对象、COM对象等都是通过引用来实现的。而CString也是通过这样的机制来管理分配的内存块。实际上CString对象只有一个指针成员变量,所以任何CString实例的长度只有4字节.

即: int len = sizeof(CString);//len等于4

这个指针指向一个相关的引用内存块，如图: CString str("abcd");

‘A’

‘B’

‘C’

‘D’

   0

0x04040404 head部，为引用内存块相关信息

str 0x40404040

正因为如此，一个这样的内存块可被多个CString所引用，例如下列代码：

CString str("abcd");

CString a = str;

CString b(str);

CString c;

c = b;

上面代码的结果是：上面四个对象(str,a,b,c)中的成员变量指针有相同的值，都为0x40404040.而这块内存块怎么知道有多少个CString引用它呢？同样，它也会记录一些信息。如被引用数，串长度，分配内存长度。

这块引用内存块的结构定义如下：

struct CStringData

{

long nRefs; //表示有多少个CString 引用它. 4

int nDataLength; //串实际长度. 4

int nAllocLength; //总共分配的内存长度（不计这头部的12字节）. 4

};

由于有了这些信息，CString就能正确地分配、管理、释放引用内存块。

如果你想在调试程序的时候获得这些信息。可以在Watch窗口键入下列表达式：

(CStringData*)((CStringData*)(this->m_pchData)-1)或

(CStringData*)((CStringData*)(str.m_pchData)-1)//str为指CString实例

正因为采用了这样的好机制，使得CString在大量拷贝时，不仅效率高，而且分配内存少。

2．LPCTSTR 与 GetBuffer(int nMinBufLength)

这两个函数提供了与标准C的兼容转换。在实际中使用频率很高，但却是最容易出错的地方。这两个函数实际上返回的都是指针，但它们有何区别呢？以及调用它们后，幕后是做了怎样的处理过程呢？

(1) LPCTSTR 它的执行过程其实很简单，只是返回引用内存块的串地址。 它是作为操作符重载提供的，所以在代码中有时可以隐式转换，而有时却需强制转制。如：

CString str;

const char* p = (LPCTSTR)str;

//假设有这样的一个函数，Test(const char* p)； 你就可以这样调用

Test(str);//这里会隐式转换为LPCTSTR

(2) GetBuffer(int nMinBufLength) 它类似，也会返回一个指针，不过它有点差别,返回的是LPTSTR

(3) 这两者到底有何不同呢？我想告诉大家，其本质上完全不一样，一般说LPCTSTR转换后只应该当常量使用，或者做函数的入参；而GetBuffer(...)取出指针后，可以通过这个指针来修改里面的内容，或者做函数的出参。为什么呢？也许经常有这样的代码：

CString str("abcd");

char* p = (char*)(const char*)str;

p[2] = 'z';

其实，也许有这样的代码后，你的程序并没有错，而且程序也运行得挺好。但它却是非常危险的。再看

CString str("abcd");

CString test = str;

....

char* p = (char*)(const char*)str;

p[2] = 'z';

strcpy(p, "akfjaksjfakfakfakj");//这下完蛋了

你知道此时，test中的值是多少吗？答案是"abzd"。它也跟着改变了，这不是你所期望发生的。但为什么会这样呢？你稍微想想就会明白，前面说过，因为CString是指向引用块的，str与test指向同一块地方,当你p[2]='z'后，当然test也会随着改变。所以用它做LPCTSTR做转换后，你只能去读这块数据，千万别去改变它的内容。

假如我想直接通过指针去修改数据的话，那怎样办呢？就是用GetBuffer(...).看下述代码：

CString str("abcd");

CString test = str;

....

char* p = str.GetBuffer(20);

p[2] = 'z'; // 执行到此，现在test中值却仍是"abcd"

strcpy(p, "akfjaksjfakfakfakj"); // 执行到此，现在test中值还是"abcd"

为什么会这样？其实GetBuffer(20)调用时，它实际上另外建立了一块新内块存，并分配20字节长度的buffer，而原来的内存块引用计数也相应减1. 所以执行代码后str与test是指向了两块不同的地方，所以相安无事。

(4) 不过这里还有一点注意事项：就是str.GetBuffer(20)后，str的分配长度为20，即指针p它所指向的buffer只有20字节长，给它赋值时，切不可超过，否则灾难离你不远了；如果指定长度小于原来串长度，如GetBuffer(1),实际上它会分配4个字节长度（即原来串长度）；另外，当调用GetBuffer(...)后并改变其内容，一定要记得调用ReleaseBuffer(),这个函数会根据串内容来更新引用内存块的头部信息。

(5) 最后还有一注意事项，看下述代码：

char* p = NULL;

const char* q = NULL;

{

CString str = "abcd";

q = (LPCTSTR)str;

p = str.GetBuffer(20);

AfxMessageBox(q);// 合法的

strcpy(p, "this is test");//合法的，

}

AfxMessageBox(q);// 非法的，可能完蛋

strcpy(p, "this is test");//非法的，可能完蛋

这里要说的就是，当返回这些指针后， 如果CString对象生命结束，这些指针也相应无效。

3．拷贝 & 赋值 & "引用内存块" 什么时候释放？

下面演示一段代码执行过程

void Test()

{

CString str("abcd");

//str指向一引用内存块（引用内存块的引用计数为1,长度为4,分配长度为4）

CString a;

//a指向一初始数据状态，

a = str;

//a与str指向同一引用内存块（引用内存块的引用计数为2,长度为4,分配长度为4）

CString b(a);

//a、b与str指向同一引用内存块（引用内存块的引用计数为3,长度为4,分配长度为4）

{

LPCTSTR temp = (LPCTSTR)a;

//temp指向引用内存块的串首地址。（引用内存块的引用计数为3,长度为4,分配长度为4）

CString d = a;

//a、b、d与str指向同一引用内存块（引用内存块的引用计数为4, 长度为4,分配长度为4）

b = "testa";

//这条语句实际是调用CString::operator=(CString&)函数。 b指向一新分配的引用内存块。（新分配的引用内存块的 引用计数为1, 长度为5, 分配长度为5）

//同时原引用内存块引用计数减1. a、d与str仍指向原 引用内存块（引用内存块的引用计数为3,长度为4,分配长度为4）

}

//由于d生命结束，调用析构函数，导至引用计数减1（引用内存块的引用计数为2,长度为4,分配长度为4）

LPTSTR temp = a.GetBuffer(10);

//此语句也会导致重新分配新内存块。temp指向新分配引用内存块的串首地址（新 分配的引用内存块的引用计数为1,长度为0,分配长度为10）

//同时原引用内存块引用计数减1. 只有str仍 指向原引用内存块 （引用内存块的引用计数为1, 长度为4, 分配长度为4）

strcpy(temp, "temp");

//a指向的引用内存块的引用计数为1,长度为0,分配长度为10 a.ReleaseBuffer();//注意:a指向的引用内存块的引用计数为1,长度为4,分配长度为10

}

//执行到此，所有的局部变量生命周期都已结束。对象str a b 各自调用自己的析构构

//函数，所指向的引用内存块也相应减1

//注意，str a b 所分别指向的引用内存块的计数均为0,这导致所分配的内存块释放

//CString分配的内存在堆里，只有这块 引用内存块的计数均为0，才释放内存

通过观察上面执行过程，我们会发现CString虽然可以多个对象指向同一引用内块存，但是它们在进行各种拷贝、赋值及改变串内容时，它的处理是很智能并且非常安全的，完全做到了互不干涉、互不影响。当然必须要求你的代码使用正确恰当，特别是实际使用中会有更复杂的情况，如做函数参数、引用、及有时需保存到CStringList当中，如果哪怕有一小块地方使用不当，其结果也会导致发生不可预知的错误

5 FreeExtra()的作用

看这段代码

(1) CString str("test");

(2) LPTSTR temp = str.GetBuffer(50);

(3) strcpy(temp, "there are 22 character");

(4) str.ReleaseBuffer();

(5) str.FreeExtra();

上面代码执行到第(4)行时，大家都知道str指向的引用内存块计数为1,长度为22,分配长度为50. 那么执行str.FreeExtra()时，它会释放所分配的多余的内存。(引用内存块计数为1,长度为22,分配长度为22)

6 Format(...) 与 FormatV(...)

这条语句在使用中是最容易出错的。因为它最富有技巧性，也相当灵活。在这里，我没打算对它细细分析，实际上sprintf(...)怎么用，它就怎么用。我只提醒使用时需注意一点：就是它的参数的特殊性，由于编译器在编译时并不能去校验格式串参数与对应的变元的类型及长度。所以你必须要注意，两者一定要对应上，

否则就会出错。如：

CString str;

int a = 12;

str.Format("first:%l, second: %s", a, "error");//result?试试

7 LockBuffer() 与 UnlockBuffer()

顾名思议，这两个函数的作用就是对引用内存块进行加锁及解锁。但使用它有什么作用及执行过它后对CString串有什么实质上的影响。其实挺简单，看下面代码:

(1) CString str("test");

(2) str.LockBuffer();

(3) CString temp = str;

(4) str.UnlockBuffer();

(5) str.LockBuffer();

(6) str = "error";

(7) str.ReleaseBuffer();

执行完(3)后，与通常情况下不同，temp与str并不指向同一引用内存块。你可以在watch窗口用这个表达式(CStringData*)((CStringData*)(str.m_pchData)-1)看看。

其实在msdn中有说明：

While in a locked state, the string is protected in two ways:

No other string can get a reference to the data in the locked string, even if that string is assigned to the locked string.

The locked string will never reference another string, even if that other string is copied to the locked string.

8 CString 只是处理串吗？

不对，CString不只是能操作串，而且还能处理内存块数据。功能完善吧！看这段代码

char p[20];

for(int loop=0; loop<sizeof(p); loop++)

{

p[loop] = 10-loop;

}

CString str((LPCTSTR)p, 20);

char temp[20];

memcpy(temp, str, str.GetLength());

str完全能够转载内存块p到内存块temp中。所以能用CString来处理二进制数据

8 AllocSysString()与SetSysString(BSTR*)

这两个函数提供了串与BSTR的转换。使用时须注意一点：当调用AllocSysString()后，须调用它SysFreeString(...)

9 参数的安全检验

在MFC中提供了多个宏来进行参数的安全检查，如：ASSERT. 其中在CString中也不例外，有许多这样的参数检验，其实这也说明了代码的安全性高，可有时我们会发现这很烦，也导致Debug与Release版本不一样，如有时程序Debug通正常，而Release则程序崩溃；而有时恰相反，Debug不行，Release行。其实我个人认为，我们对CString的使用过程中，应力求代码质量高，不能在Debug版本中出现任何断言框，哪怕release运行似乎看起来一切正常。但很不安全。如下代码：

(1) CString str("test");

(2) str.LockBuffer();

(3) LPTSTR temp = str.GetBuffer(10);

(4) strcpy(temp, "error");

(5) str.ReleaseBuffer();

(6) str.ReleaseBuffer();//执行到此时，Debug版本会弹出错框

10 CString的异常处理

我只想强调一点：只有分配内存时，才有可能导致抛出CMemoryException.

同样，在msdn中的函数声明中，注有throw( CMemoryException)的函数都有重新分配或调整内存的可能。

11 跨模块时的Cstring。即一个DLL的接口函数中的参数为CString&时，它会发生怎样的现象。解答我遇到的问题。我的问题原来已经发贴，地址为：

http://www.csdn.net/expert/topic/741/741921.xml?temp=.2283136

构造一个这样CString对象时，如CString str，你可知道此时的str所指向的引用内存块吗？也许你会认为它指向NULL。其实不对，如果这样的话，CString所采用的引用机制管理内存块就会有麻烦了，所以CString在构造一个空串的对象时，它会指向一个固定的初始化地址，这块数据的声明如下：

AFX_STATIC_DATA int _afxInitData[] = {-1,0,0,0};

简要描述概括一下：当某个CString对象串置空的话，如Empty(),CString a等，它的成员变量m_pchData就会指向_afxInitData这个变量的地址。当这个CString对象生命周期结束时，正常情况下它会去对所指向的引用内存块计数减1，如果引用计数为0(即没有任何CString引用它时)，则释放这块引用内存。而现在的情况是如果CString所指向的引用内存块是初始化内存块时，则不会释放任何内存。

说了这么多，这与我遇到的问题有什么关系呢？其实关系大着呢？其真正原因就是如果exe模块与dll模块有一个是static编译连接的话。那么这个CString初始化数据在exe模块与dll模块中有不同的地址，因为static连接则会在本模块中有一份源代码的拷贝。另外一种情况，如果两个模块都是share连接的，CString的实现代码则在另一个单独的dll中实现，而AFX_STATIC_DATA指定变量只装一次，所以两个模块中_afxInitData有相同的地址。

现在问题完全明白了吧！你可以自己去演示一下。

__declspec (dllexport) void test(CString& str)

{

str = "abdefakdfj";//如果是static连接，并且传入的str为空串的话，这里出错。

}

最后一点想法：写得这里，其实CString中还有许多技巧性的好东东，我并没去解释。如很多重载的操作符、查找等。我认为还是详细看看msdn，这样也许会比我讲的好多了。我只侧重那些可能会出错的情况。当然，如我上面叙述中有错误，敬请高手指点，不胜感谢！


msdn：http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmfc98/html/_mfc_cstring_class_members.asp

1.AfxGetStaticModuleState()指向当前模块状态;

2.当前函数调用结束后原模块的状态自动被恢复；

3.用于DLL中所调用MFC函数、类、资源时的模块状态切换;

究其原因，就debug版中的堆栈中的局部变量（包括指针）在明确初始化之前都用0x0cc进行初始化，因此，未初始化时候的指针是指向地址0x0cccccccc的，而这段地址一来是处于内核地址空间，一般的应用程序是无权访问的，上面的报错就是这样产生的。因此，一旦遇到上述报错，基本可以认定程序中出现了野指针。

另外一方面cc对应着int 3调试中断，堆栈中的存放的局部数据一般情况下是只读的，当发生意外执行堆栈里面的数据就会引发该调试中断。

可以认为0x0cc就是有特殊含义的占位符，对于指针而言，它跟NULL是一个意思，其它具有特殊意义的占位符还有：

0xcdcdcdcd - Created but not initialized

0xdddddddd - Deleted

0xfeeefeee - Freed memory set by NT's heap manager

0xcccccccc - Uninitialized locals in VC6 when you compile w/ /GZ

0xabababab - Memory following a block allocated by LocalAlloc()

在VC编译器下，如果您用最高级别进行编译，编译器就会很苛刻地指出您的非常细小的警告。当你生命了一个变量，而没有使用时，编译器就会报警告：

“warning C4100: ''ＸＸＸＸ'' : unreferenced formal parameter.”

所以，为了让编译器不必检测你的警告，就使用UNREFERENCED_PARAMETER语句。比如：

int SomeFunction(int arg1, int arg2)
{
  UNREFERENCED_PARAMETER(arg2)
  ...
}

===============================================================================

    [ 翻译文档 本文适合中级读者 已阅读9439次 ]   文档 代码 工具  

C++ At Work 专栏...
未引用参数，添加任务栏命令及其它...

原著：Paul DiLascia
翻译：NorthTibet

下载源代码：CAtWork0505.exe (171KB)
原文出处：Unreferenced Parameters, Adding Task Bar Commands, and More

未引用参数
添加任务栏命令

 我看到过一些 C++ 代码针对没有使用过的参数用 UNREFERENCED_PARAMETER，例如：

int SomeFunction(int arg1, int arg2)
{
  UNREFERENCED_PARAMETER(arg2)
  ...
}
我还看到过这样的代码：
int SomeFunction(int arg1, int /* arg2 */)
{
  ...
}
你能解释它们的差别吗？哪一种用法更好？

Judy McGeough

 是啊！为什么呢？让我们从 UNREFERENCED_PARAMETER 开始吧。这个宏在 winnt.h 中定义如下：
#define UNREFERENCED_PARAMETER(P) (P)　　换句话说 UNREFERENCED_PARAMETER 展开传递的参数或表达式。其目的是避免编译器关于未引用参数的警告。许多程序员，包括我在内，喜欢用最高级别的警告 Level 4（/W4）进行编译。Level 4 属于“能被安全忽略的事件”的范畴。虽然它们可能使你难堪，但很少破坏你的代码。例如，在你的程序中可能会有这样一些代码行：

int x=1;　　但你从没用到过 x。也许这一行是你以前使用 x 时留下来的，只删除了使用它的代码，而忘了删除这个变量。Warning Level 4 能找到这些小麻烦。所以，为什么不让编译器帮助你完成可能是最高级别的专业化呢？用Level 4 编译是展示你工作态度的一种方式。如果你为公众使用者编写库，Level 4 则是社交礼节上需要的。你不想强迫你的开发人员使用低级选项清洁地编译他们的代码。
　　问题是，Level 4 实在是太过于注意细节，在 Level 4 上，编译器连未引用参数这样无伤大雅的事情也要抱怨（当然，除非你真的有意使用这个参数，这时便相安无事）。假设你有一个函数带来两个参数，但你只使用其中一个：

int SomeFunction(int arg1, int arg2)
{
    return arg1+5;
}使用 /W4，编译器抱怨：

“warning C4100: ''arg2'' : unreferenced formal parameter.”为了骗过编译器，你可以加上 UNREFERENCED_PARAMETER(arg2)。现在编译器在编译你的引用 arg2 的函数时便会住口。并且由于语句：

arg2;实际上不做任何事情，编译器不会为之产生任何代码，所以在空间和性能上不会有任何损失。

　　细心的人可能会问：既然你不使用 arg2，那当初为何要声明它呢？通常是因为你实现某个函数以满足某些API固有的署名需要，例如，MFC的 OnSize 处理例程的署名必须要像下面这样：

void OnSize(UINT nType, int cx, int cy);　　这里 cx/cy 是窗口新的宽/高，nType 是一个类似 SIZE_MAXIMIZED 或 SIZE_RESTORED 这样的编码，表示窗口是否最大化或是常规大小。一般你不会在意 nType，只会关注 cx 和 xy。所以如果你想用 /W4，则必须使用 UNREFERENCED_PARAMETER(nType)。OnSize 只是上千个 MFC 和 Windows 函数之一。编写一个基于 Windows 的程序，几乎不可能不碰到未引用参数。
　　说了这么多关于 UNREFERENCED_PARAMETER 内容。Judy 在她的问题中还提到了另一个 C++ 程序员常用的并且其作用与 UNREFERENCED_PARAMETER 相同的诀窍，那就是注释函数署名中的参数名：

void CMyWnd::OnSize(UINT /* nType */,
int cx, int cy)
{
}　　现在 nType 是未命名参数，其效果就像你敲入 OnSize(UINT, int cx, int cy)一样。那么现在的关键问题是：你应该使用哪种方法——未命名参数，还是 UNREFERENCED_PARAMETER？
　　大多数情况下，两者没什么区别，使用哪一个纯粹是风格问题。（你喜欢你的 java 咖啡是黑色还是奶油的颜色？）但我认为至少有一种情况必须使用 UNREFERENCED_PARAMETER。假设你决定窗口不允许最大化。那么你便禁用 Maximize 按钮，从系统菜单中删除，同时阻止每一个用户能够最大化窗口的操作。因为你是偏执狂（大多数好的程序员都是偏执狂），你添加一个 ASSERT （断言）以确保代码按照你的意图运行：

void CMyWnd::OnSize(UINT nType, int cx, int cy)
{
    ASSERT(nType != SIZE_MAXIMIZE);
    ... // use cx, cy
}　　质检团队竭尽所能以各种方式运行你的程序，ASSERT 从没有弹出过，于是你认为编译生成 Release 版本是安全的。但是此时 _DEBUG 定义没有了，ASSERT(nType != SIZE_MAXIMIZE)展开为 ((void)0)，并且 nType 一下子成了一个未引用参数！这样进入你干净的编译。你无法注释掉参数表中的 nType，因为你要在 ASSERT 中使用它。于是在这种情况下——你唯一使用参数的地方是在 ASSERT 中或其它 _DEBUG 条件代码中——只有 UNREFERENCED_PARAMETER 会保持编译器在 Debug 和 Release 生成模式下都没有问题。知道了吗？
　　结束讨论之前，我想还有一个问题我没有提及，就是你可以象下面这样用 pragma 指令抑制单一的编译器警告：

#pragma warning( disable : 4100 )4100 是未引用参数的出错代码。pragma 抑制其余文件/模块的该警告。用下面方法可以重新启用这个警告：

#pragma warning( default : 4100 )　　不管怎样，较好的方法是在禁用特定的警告之前保存所有的警告状态，然后，等你做完之后再回到以前的配置。那样，你便回到的以前的状态，这个状态不一定是编译器的默认状态。
　　所以你能象下面这样在代码的前后用 pragma 指令抑制单个函数的未引用参数警告：

#pragma warning( push )
#pragma warning( disable : 4100 )
void SomeFunction(...)
{
}
#pragma warning( pop )　　当然，对于未引用参数而言，这种方法未免冗长，但对于其它类型的警告来说可能就不是这样了。库生成者都是用 #pragma warning 来阻塞警告，这样他们的代码可以用 /W4 进行清洁编译。MFC 中充满了这样的 pragmas 指令。还有好多的 #pragma warning 选项我没有在本文讨论。有关它们的信息请参考相关文档。

 我注意到一些应用程序，当右键单击其任务栏最小化按钮时，在弹出的上下文菜单中具备特殊的命令。例如，WinAmp（一个流行的媒体播放器）有一个附加的 “WinAmp”菜单项，其中是 WinAmp 特有的命令。我如何在程序的任务栏按钮中添加我自己的菜单项？

Jirair Osygian

 我创建了一个简单的 MFC SDI 程序，该程序用表单视图（Form View）显示一个计数器。我想通过右键单击任务栏上程序的最小化按钮来控制启动/停止这个计数器。在表单视图上通过按钮控制的启动/停止功能运行正常，我也能将启动/停止命令加到系统菜单。但我单击加入的系统菜单时没反应。我如何处理这些定制的系统菜单消息？

Monicque Sharman
 我两个问题一起回答，Jirair 问题的答案很简单：当你右键单击任务栏上应用程序的最小化按钮时，用户看到的菜单与用户单击左上角应用程序标题栏图标或按 Alt+Space 所看到的菜单一样。如 Figure 1 所示。这个菜单被称为系统菜单，其中包括命令如：还原、最小化、最大化和关闭等。

Figure 1 系统菜单

　　你可以调用 ::GetSystemMenu 来获得此系统菜单，然后可以添加、删除或修改菜单项。你甚至可以通过关掉 WS_SYSMENU 窗口创建式样标志或 PreCreateWindow 虚函数来完全屏蔽掉这个系统菜单。但不论你做什么，当用户右键单击任务栏上应用程序的最小化按钮时，这个系统菜单还是会显示出来的。
　　到了 Monicque 的问题：如果在系统菜单中添加自己的命令，MFC 是如何处理它们的呢？如果按常规来做 ——在某个地方写一个 ON_COMMAND 处理器并将它加到消息映射中，你会发现你的处理器不起作用，怎么会这样呢？
　　那是因为 Windows 和 MFC 处理系统命令的方式与处理普通菜单命令的方式不一样。当用户调用窗体中的常规菜单命令或按钮时，Windows 向主窗口发送一个 WM_COMMAND 消息。如果你使用 MFC，那么其命令路由机制将捕获此消息并通过操作系统将它路由到该命令的 ON_COMMAND 命令处理器对象。（有关 MFC 命令处理机制的详细内容，参见我在 MSJ 1995年7月发表的文章：“Meandering Through the Maze of MFC Message and Command Routing”）。
　　然而系统命令不属于 WM_COMMAND 消息范围。而属于另外一个叫做——WM_SYSCOMMAND 的消息。不论命令ID是真正的系统命令如 SC_MINIMIZE 和 SC_CLOSE，还是你自己添加的其它命令ID都是如此。为了处理系统菜单命令，你必须处理显式处理 WM_SYSCOMMAND 并且要选择你自己的命令 IDs。这就需要你在主窗口消息映射中添加ON_WM_SYSCOMMAND，它有一个处理函数如下：
CMainFrame::OnSysCommand(UINT nID, LPARAM lp)
{
    if (nID==ID_MY_COMMAND) {
        ... // 处理它
        return 0;
    }

    // 传递到基类：这一步很重要!
    return CFrameWnd::OnSysCommand(nID, lp);
}　　如果该命令不是你的，不要忘了将它传递到你的基类处理——典型地，那就是 CFrameWnd 或 CMDIFrameWnd。否则，Windows 将无法得到此消息，并且会破坏内建的命令。
　　在主框架中处理 WM_SYSCOMMAND 固然可以，但这样做感觉太业余。为什么要用特殊的机制来处理呢？就因为它们是系统菜单吗？如果你想在视图或文档对象中处理系统命令会怎样呢？有一个常见的命令放到了系统菜单中，它就是“关于”（ID_APP_ABOUT），大多数 MFC 程序都是在应用程序对象中处理 ID_APP_ABOUT：

void CMyApp::OnAppAbout()
{
    static CAboutDialog dlg;
    dlg.DoModal();
}　　MFC 一个真正很酷的特性是它的命令路由系统，它使得象 CMyApp 这样的非窗口对象也能处理菜单命令。许多程序员甚至都不了解怎么会有这样的例外。如果你已经在应用程序对象中处理 ID_APP_ABOUT，那把ID_APP_ABOUT 添加到系统菜单后，为什么还要去实现一套单独的机制？
　　处理外加系统命令的比较好的，或者说更 MFC 的方法应该是通过常规的命令路由机制传递它们。然后按 MFC 常规方法编写 ON_COMMAND 处理例程来处理系统命令。你甚至可以用 ON_UPDATE_COMMAND_UI 来更新你的系统菜单项，例如禁用某个菜单项或在菜单项旁边显示一个检讫标志。
　　Figure 2 是我写的一个类，CSysCmdRouter，这个类将系统命令转成常规命令。为了使用这个类，你要做的只是在主框架中实例化 CSysCmdRouter，并从 OnCreate 中调用其 Init 方法即可：

int CMainFrame::OnCreate(...)
{
    // 将我的菜单项添加到系统菜单
    CMenu* pMenu = GetSystemMenu(FALSE);
    pMenu->AppendMenu(..ID_MYCMD1..);
    pMenu->AppendMenu(..ID_MYCMD2..);

    // 通过 MFC 路由系统命令
    m_sysCmdHook.Init(this);
    return 0;
}　　一旦你调用 CSysCmdRouter::Init，你便可以按常规方式处理 ID_MYCMD1 和 ID_MYCMD2，为 MFC 命令路由机制中的任何对象编写 ON_COMMAND 处理例程——视图，文档，框架，应用程序或通过改写 OnCmdMsg 添加的任何其它命令对象。CSysCmdRouter 还让你用 ON_UPDATE_COMMAND_UI 处理器更新系统菜单。唯一要注意的是确保命令IDs不要与其它菜单命令（除非他们确实代表相同的命令）或内建系统命令发生冲突，内建系统命令从 SC_SIZE = 0xF000 开始。Visual Studio .NET 指定的命令 IDs 从 0x8000 = 32768 开始，所以如果你让 Visual Studio 来指定 IDs，只要不超过 0xF000-0x8000 = 0x7000 个命令即可。也就是十进制的 28,762。如果你的应用程序有超过 28000 个命令，那么你需要咨询编程精神病专家。
　　CSysCmdRouter 是如何实现其魔法的呢？简单：它使用我那个以前专栏中无处不在的 CSubclassWnd。CSubclassWnd 使你不用从其派生便能子类化 MFC 窗口对象。CSysCmdRouter 派生自 CSubclassWnd 并使用它子类化主框架。尤其是它截获发送到框架的 WM_SYSCOMMAND 消息。如果命令 ID 属于系统命令（大于 SC_SIZE = 0xF000），则 CSysCmdRouter 沿着 Windows 一路传递该消息；否则便吃掉 WM_SYSCOMMAND 并重新将它作为 WM_COMMAND 发送，于是 MFC 按照其常规路由过程，调用你的 ON_COMMAND 处理器。很聪明，是不是？
　　那么 ON_UPDATE_COMMAND_UI 处理器呢？CSysCmdRouter 是如何让它处理系统菜单命令的呢？很简单。就在 Windows 显示菜单前，他向你的主窗口发送一个 WM_INITMENUPOPUP 消息。这是你更新菜单项的最佳时机——启用或禁用它们，添加检讫标志等等。MFC 为每个菜单项创建一个 CCmdUI 对象并将它传递到你的消息映射中相应的 ON_UPDATE_COMMAND_UI 处理器。以它为参数的 MFC 函数是 CFrameWnd::OnInitMenuPopup，这个函数是这样的：

void CFrameWnd::OnInitMenuPopup(CMenu* pMenu, UINT nIndex, BOOL bSysMenu)
{
    if (bSysMenu)
    return; // don''t support system menu
    ...
}　　MFC 初始化系统菜单时不做任何事情。为什么要去关心这种事呢？万一你要让 bSysMenu 为 FALSE，即使是系统菜单，那该怎么办？这恰恰是 CSysCmdRouter 做的事情。它截取 WM_INITMENUPOPUP 并清除 bSysMenu 标志，也就是 LPARAM 的 HIWORD：

if (msg==WM_INITMENUPOPUP) {
    lp = LOWORD(lp); // (set HIWORD = 0)
}　　现在，当 MFC 获得 WM_INITMENUPOPUP，它认为该菜单是常规菜单。只要你的命令 IDs 与真正的系统菜单不冲突，一切都运行得很好。如果你改写 OnInitMenuPopup，唯一丢失的东西是不能从主窗口菜单中区分系统菜单。嘿，你不能什么都想要！通过改写 CWnd::WindowProc，你总是能处理 WM_INITMENUPOPUP 的，或你想要区分，就比较 HMENUs。但你确实不用关心命令来自何处。

Figure 3 任务栏菜单

　　为了展示所有的实践，我写了一个小测试程序： TBMenu。如图 Figure 3 所示，当你右键单击任务栏上 TBMenu 的最小化按钮，便会显示出菜单。你可以看到在菜单底部有两个额外的命令。TBMenu 的 CMainFrame代码如 Figure 4 所示。便知道在 OnCreate 的什么地方添加命令并在 CMainFrame 的消息映射中用 ON_COMMAND 以及 ON_UPDATE_COMMAND_UI 处理器处理它们。TBMenu 在其应用程序类中处理 ID_APP_ABOUT（代码未列出）。CSysCmdRouter 使系统命令的工作机制类似其它命令。

说到命令，我们来看看一个小资料：

　　在我一月份的专栏中，我问是否有人知道 Ctrl+Alt+Del 的由来。显然，有几个读者知道如何使用 Google，因为他们发给我的是相同的链接：《今日美国》上的一篇文章：“Thank this guy for 'control-alt-delete'”，我在一月发问之前就发现了这篇文章。Ctrl+Alt+Del 是由一个名叫 David J. Bradley 的人发现的，他在 IBM 工作过。
IBM 觉得应该有一种方法不用关闭电源就能重置（reset）其新的 PC 机。为什么要专门用 Ctrl+Alt+Del 这三个键呢？从技术上来说，David 需要使用两个修饰键。他想要一种没有人可能意外敲入的键组合。所以他选择了
Ctrl+Alt 作为修饰键（比 Shift 用得少）和 Delete，此键位于键盘的另一端，所以敲击 Ctrl+Alt+Del 需要两只手，至少在过去是这样做的。
当今现代键盘在右边也有 Ctrl 和 Alt 键。重启特性的初衷是为 IBM 的人设计的秘密安全出口，但不可避免地，它已经成为一个不是秘密的秘密。一旦开发人员知道了它，他们便开始告诉客户使用这个特性来解决机器挂起问题。随着历史的发展，Ctrl+Alt+Del 被人们亲切地成为“三指敬礼”，即便是在当今的 Windows 中仍然具有生命力，用它调出任务管理器，以便你能杀死挂起的任务或终止系统（更多有关类似 Ctrl+Alt+Del 安全键序列的内容，参见本月的 Security Briefs 专栏）。那么，如果 Ctrl+Alt+Del 失败了怎么办？为什么会失败，请按住它保持 5 秒钟。
　　David Bradley 是当初建立 IBM 个人计算机的 12 个工程师之一。他编写了 ROM BIOS，有关 David 的简介，参见 David J. Bradley。

祝编程愉快！

您的提问和评论可发送到 Paul 的信箱：cppqa@microsoft.com
　
 
 作者简介
　　Paul DiLascia 是一名自由作家，顾问和 Web/UI 设计者。他是《Writing Reusable Windows Code in C++》书（Addison-Wesley, 1992）的作者。通过 http://www.dilascia.com 可以获得更多了解。 　
本文出自 MSDN Magazine 的 May 2005 期刊，可通过当地报摊获得，或者最好是 订阅
 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/liuchanghe/archive/2006/12/31/1471302.aspx

以前只是简单是使用sscanf,却没发现其还有如此强大的功能
 char str0[100],str1[100],str2[100],str3[100];

 sscanf("abcde abc 123 aaa","%s %s %s %s",str0,str1,str2,str3);
 结果:str0="abcde"   str1="abc"  str2 = "123" str3="aaa"

 sscanf("abcde abc 123 aaa","abc%s %s %*d %s",str0,str1,str3);
 结果:str0="abcde"   str1="abc"  str3="aaa"

 sscanf("abc123 efg456","%4s",str0);
 结果:str0="abc1"   

 sscanf("abc123 efg456a4","%[a-z 1-5]",str0);
 结果:str0="abc123 efg45"   

sscanf("abc123 efg456a4","%[a-z1-5]",str0);
 结果:str0="abc123" 

 sscanf("ABCTabcZ123 efg456","%[A-P]",str0);
 结果:str0="ABC"   

 sscanf("abc 12345","%[^ ]",str0);
 结果:str0="abc"   

 sscanf("abc 12345","%[^4]",str0);
 结果:str0="abc 123"   

 sscanf("fdaBs 52aB1asdf","%[^4-0]",str0);
 结果:str0="fdaBs 5"   

 sscanf("abc 12345","%[^ ]%[^3]",str0,str1);
 结果:str0="abc"    str1="12"

 sscanf("abc301abc2345","%*[^9-0]%s",str0); 
 结果:str0="301abc2345"   
 sscanf("bca@123efg4@5abc","%*[^@]@%[^@]",str0);
 结果:str0="123efg4"