通过编写串口助手工具学习MFC过程
因为以前也做过几次MFC的编程，每次都是项目完成时，MFC基本操作清楚了，但是过好长时间不再接触MFC的项目，再次做MFC的项目时，又要从头开始熟悉。这次通过做一个串口助手再次熟悉一下MFC，并做了一下记录，以便方便以后查阅。做的过程中多是遇到问题直接百度和谷歌搜索来的，所以很多都是不求甚解，知其然不知其所以然。另外做此工具只是为了熟悉了解，许多功能还没有完善！（开发工具VS2008）
（八）遇到的一些问题
本例中用到的控件就介绍完了，本节是在本例过程中遇到的一些问题
1、解决使用枚举串口类而造成无法解析的外部符号的问题
最近在开发一个串口通信程序，使用的是Zach Gorman提供的类。不过在vs2005下，会出现如下的情况：
1>------ 已启动生成: 项目: Communication, 配置: Debug Win32 ------
1>正在编译...
1>EnumSerial.cpp
1>正在链接...
1>EnumSerial.obj : error LNK2019: 无法解析的外部符号 [email protected]，该符号在函数 [email protected]@[email protected]@@[email protected]@@@Z$0 中被引用
1>EnumSerial.obj : error LNK2019: 无法解析的外部符号 [email protected]，该符号在函数 "void __cdecl EnumPortsWdm(class CArray<struct SSerInfo,struct SSerInfo &> &)" ([email protected]@[email protected]@@[email protected]@@@Z) 中被引用
1>EnumSerial.obj : error LNK2019: 无法解析的外部符号 [email protected]，该符号在函数 "void __cdecl EnumPortsWdm(class CArray<struct SSerInfo,struct SSerInfo &> &)" ([email protected]@[email protected]@@[email protected]@@@Z) 中被引用
1>EnumSerial.obj : error LNK2019: 无法解析的外部符号 [email protected]，该符号在函数 "void __cdecl EnumPortsWdm(class CArray<struct SSerInfo,struct SSerInfo &> &)" ([email protected]@[email protected]@@[email protected]@@@Z) 中被引用
1>EnumSerial.obj : error LNK2019: 无法解析的外部符号 [email protected]，该符号在函数 "void __cdecl EnumPortsWdm(class CArray<struct SSerInfo,struct SSerInfo &> &)" ([email protected]@[email protected]@@[email protected]@@@Z) 中被引用
1>C:\Documents and Settings\Administrator\桌面\DEV\ModBus通信协议demo -09-20\Debug\Communication.exe : fatal error LNK1120: 5 个无法解析的外部命令
1>生成日志保存在“file://c:\Documents and Settings\Administrator\桌面\DEV\ModBus通信协议demo -09-20\Communication\Debug\BuildLog.htm”
1>Communication - 6 个错误，0 个警告
========== 生成: 0 已成功, 1 已失败, 0 最新, 0 已跳过 ==========
这是因为VS2005中没有给我们导入setupapi.dll文件，有两种解决办法：
1：在你的.h文件中的开始位置插入#pragma comment(lib,"setupapi")即可
2：或者按下图设置
引用：http://blog.csdn.net/l_peter/article/details/7599122
2、MFC添加对话框报错：enum { IDD = xxx};“xxx”: 未声明的标识符
xxx是添加对话框的id，代码在对话框对应类 xxx.h文件对话框类声明时有代码enum { IDD = xxx};
解决方案在xxx.h文件添加#include "resource.h"
3、MFC 程序如何使用 printf 输出调试信息
设想一下，我们在 win32 控制台下写了个在命令行运行的程序库，图方便直接用 printf 输出 log 来进行调试，但后来集成库时使用了 MFC 之类的窗体程序，于是原先用 printf 输出的 log 信息都看不到了，但是我们又需要查看这些 log 信息，甚至最好能输出到文件来方便进行分析，如何处理？
首先，我们考虑将 log 信息输出到控制台上，按照以下步骤操作。
1，添加头文件
|
1 2 |
#include <io.h> #include <fcntl.h> |
2，把下面的函数加到将要调用的文件中
|
1 2 3 4 5 6 7 8 |
void InitConsoleWindow() { AllocConsole(); HANDLE handle = GetStdHandle(STD_OUTPUT_HANDLE); int hCrt = _open_osfhandle((long)handle,_O_TEXT); FILE * hf = _fdopen( hCrt, "w" ); *stdout = *hf; } |
3，在初始化函数中添加创建控制台的调用
|
1 2 3 4 5 6 7 8 9 10 |
BOOL CHelloMFCDlg::OnInitDialog() { CDialog::OnInitDialog(); InitConsoleWindow(); // add printf("str = %s ", "Debug output goes to terminal "); ...... } |
调用此函数后会弹出一个 Console，printf 的信息就会出现在这上面，我们就可以查看 log 信息了。但是，如果 log 信息输出过多，Console 上面就不能显示全部信息，这时我们便希望通过 printf 把 log 输出到一个固定的文件中，而这就要用到了输出的重定向。
我们都知道，在 windows 终端输入”dir”会列出当前目录的文件列表，输入”dir > 1.txt”则可把当前目录的文件列表导出到”1.txt”中，linux 终端也有类似命令”ls > 1.txt”。这里用到的就是输出的重定向，我们可以用同样的思路通过 freopen 来实现 log 信息的文件输出。
先包含头文件，然后一句话就可以实现输出的重定向
|
1 2 3 4 |
#include <stdio.h> #include <stdlib.h> freopen("log.txt", "w", stdout); //redirect stdout to log.txt |
返回正常的 stdout 输出
|
1 2 |
freopen("CON", "w", stdout); //recover stdout(Windows) //freopen("/dev/console", "w", stdout); //recover stdout(Linux) |
也可以这样使用
|
1 2 3 4 5 |
FILE *outbak = stdout; stdout = fopen("log.txt", "w"); ...... fclose(stdout); stdout = outbak; |
其实，stdin 也有类似的重定向操作：
|
1 2 3 |
freopen("info.txt", "r", stdin); //redirect stdin to info.txt freopen("CON", "r", stdin); //recover(Windows) //freopen("/dev/console", "r", stdin); //recover(Linux) |
上面的方法都是在代码已经写完的情况下，通过对 printf 进行的调整来避免大量重复的劳动。当然，为了避免这一切，最好的方法是在最初写代码的时候就定义一个 log 输出宏，后续都通过这个宏来调整 log 输出。
原文http://xuhehuan.com/2297.html
4、解决头文件相互包含问题的方法
所谓超前引用是指一个类型在定义之前就被用来定义变量和声明函数。
一般情况下，C/C++要求所有的类型必须在使用前被定义，但是在一些特殊情况下，这种要求无法满足，例如，在类CMyView中保留了一个非模式对话框对象指针，该对象用于显示/修改一些信息。为了实现对话框"应用"按钮，把对话框做的修改立刻更新到view界面上，为此，需要在对话框类中需要保存view类的指针，这样定义关系就变成如下的代码：
#ifndef __MYVIEW_H__
#define __MYVIEW_H__
//这是view类的头函数
#include "MyDialog.h"
class CMyView::public CView
{
protected:
CMyDialog * pDlg;
//这里是其他定义
};
#endif
#ifndef __MYDIALOG_H__
#define __MYDIALOG_H__
//这是对话框类的定义
#include "MyView.h"
class CMyDialog::public CDialog
{
protected:
CMyView * pView;
//其他定义
};
#endif
从编译器角度看，编译MyDialog.CPP时，系统首先定义宏__MYDIALOG_H__，然后包含MyView.h，MyView.h中的#include "MyDialog.h"由于__MYDIALOG_H__已经定义，所以不再起作用。在CMyView类的声明中，CMyDialog* pDlg ;就会让编译器产生"CMyDialog"类型没有定义之类的错误，编译MyView.CPP文件出现的错误可以类似得到。
更一般的情况，类A和类B需要彼此互相引用，这样必然有一个类会先被定义，而另外一个类后被定义，这样在先被定义的类引用后被定义的类的时候，就导致了所谓的超前引用。
超前引用导致的错误有以下几种处理办法：
1) 使用类声明
在超前引用一个类之前，首先用一个特殊的语句说明该标识符是一个类名，即将被超前引用。其使用方法是：
a) 用class ClassB；声明即将超前引用的类名
b) 定义class ClassA
c) 定义class ClassB;
d) 编制两个类的实现代码。
上述方法适用于所有代码在同一个文件中，一般情况下，ClassA和ClassB分别有自己的头文件和cpp文件，这种
方法需要演变成：
a) 分别定义ClassA和ClassB，并在cpp文件中实现之
b) 在两个头文件的开头分别用class ClassB;和class ClassA;声明对方
c) 在两个cpp文件中分别包含另外一个类的头文件
NOTE:这种方法切记不可使用类名来定义变量和函数的变量参数，只可用来定义引用或者指针。
2) 使用全局变量
由于全局变量可以避免超前引用，不用赘述。我的习惯是，把类对象的extern语句加在该类头文件的最后，大家喜欢
怎样写那都没有什么大问题，关键是保证不要在头文件中胡乱包含。
3) 使用基类指针。
这种方法是在引用超前引用类的地方一律用基类指针。而一般情况下，两个互相引用的类并不涉及其基类，因此不会造成
超前引用。以开始的例子说：在CMyDialog类中用CView*代替CMyView*，在CMyView类中用CDialog*代替CMyDialog*，这样必然
不会造成超前引用。
说明：本文中，为了叙述方便，把class AClass;语句成为类AClass的声明，把class AClass开始的对AClass的类成员变量、
成员函数原型等的说明称为类的定义，而把在CPP中的部分称为类的定义。如果大家对这三个词有不同的理解，请按照自己的本意
把这三个词换成相应的词来理解。
*************************************************************************************************************************************************
一、类嵌套的疑问
C++头文件重复包含实在是一个令人头痛的问题，前一段时间在做一个简单的数据结构演示程序的时候，不只一次的遇到这种问题。假设我们有两个类A和B，分别定义在各自的有文件A.h和B.h中，但是在A中要用到B，B中也要用到A，但是这样的写法当然是错误的：
Cpp代码 
1. class B;
2. class A
3. {
4. public:
5. B b;
6. };
7.
8. class B
9. {
10. public:
11. A a;
12. };
因为在A对象中要开辟一块属于B的空间，而B中又有A的空间，是一个逻辑错误，无法实现的。在这里我们只需要把其中的一个A类中的B类型成员改成指针形式 就可以避免这个无限延伸的怪圈了。为什么要更改A而不是B？因为就算你在B中做了类似的动作，也仍然会编译错误，表面上这仅仅上一个先后顺序的问题。
为什么会这样呢？因为C++编译器自上而下编译源文件的时候，对每一个数据的定义，总是需要知道定义的数据的类型的大小。在预先声明语句class B;之后，编译器已经知道B是一个类，但是其中的数据却是未知的，因此B类型的大小也不知道。这样就造成了编译失败，VC++6.0下会得到如下编译错误：
Vc output代码 
1. error C2079: ‘b‘ uses undefined class ‘B‘
将A中的b更改为B指针类型之后，由于在特定的平台上，指针所占的空间是一定的（在Win32平台上是4字节），这样可以通过编译。
二、不同头文件中的类的嵌套
在实际编程中，不同的类一般是放在不同的相互独立的头文件中的，这样两个类在相互引用时又会有不一样的问题。重复编译是问题出现的根本原因。为了保证头文 件仅被编译一次，在C++中常用的办法是使用条件编译命令。在头文件中我们常常会看到以下语句段（以VC++6.0自动生成的头文件为例）：
Cpp代码 
1. #if !defined(AFX_STACK_H__1F725F28_AF9E_4BEB_8560_67813900AE6B__INCLUDED_)
2.
3. #define AFX_STACK_H__1F725F28_AF9E_4BEB_8560_67813900AE6B__INCLUDED_
4.
5. //很多语句……
6.
7. #endif
其中首句#if !defined也经常做#ifndef，作用相同。意思是如果没有定义过这个宏，那么就定义它，然后执行直到#endif的所有语句。如果下次在与要这段代码，由于已经定义了那个宏，因此重复的代码不会被再次执行。这实在是一个巧妙而高效的办法。在高版本的VC++上，还可以使用这个命令来代替以上的所有：
Cpp代码 
1. #pragma once
它的意思是，本文件内的代码只被使用一次。
但是不要以为使用了这种机制就全部搞定了，比如在以下的代码中：
Cpp代码 
1. //文件A.h中的代码
2. #pragma once
3. #include "B.h"
4. class A
5. {
6. public:
7. B* b;
8. };
9.
10. //文件B.h中的代码
11. #pragma once
12. #include "A.h"
13. class B
14. {
15. public:
16. A* a;
17. };
这里两者都使用了指针成员，因此嵌套本身不会有什么问题，在主函数前面使用#include "A.h"之后，主要编译错误如下：
error C2501: ‘A‘ : missing storage-class or type specifiers
Vc output代码 
1. error C2501: ‘A‘ : missing storage-class or type specifiers
仍然是类型不能找到的错误。其实这里仍然需要前置声明。分别添加前置声明之后，可以成功编译了。代码形式如下：
Cpp代码 
1. //文件A.h中的代码
2. #pragma once
3. #include "B.h"
4. class B;
5.
6. class A
7. {
8. public:
9. B* b;
10. };
11.
12. //文件B.h中的代码
13. #pragma once
14. #include "A.h"
15. class B;
16.
17. class B
18. {
19. public:
20. A* a;
21. };
这样至少可以说明，头文件包含代替不了前置声明。有的时候只能依靠前置声明来解决问题。我们还要思考一下，有了前置声明的时候头文件包含还是必要的吗？我们尝试去掉A.h和B.h中的#include行，发现没有出现新的错误。那么究竟什么时候需要前置声明，什么时候需要头文件包含呢？
三、两点原则
头文件包含其实是一想很烦琐的工作，不但我们看着累，编译器编译的时候也很累，再加上头文件中常常出现的宏定义。感觉各种宏定义的展开是非常耗时间的，远不如自定义函数来得速度。这里仅就不同头文件、源文件间的句则结构问题提出两点原则，仅供参考：
第一个原则应该是，如果可以不包含头文件，那就不要包含了。这时候前置声明可以解决问题。如果使用的仅仅是一个类的指针，没有使用这个类的具体对象（非指针），也没有访问到类的具体成员，那么前置声明就可以了。因为指针这一数据类型的大小是特定的，编译器可以获知。
第二个原则应该是，尽量在CPP文件中包含头文件，而非在头文件中。假设类A的一个成员是是一个指向类B的指针，在类A的头文件中使用了类B的前置声明并编译成功，那么在A的实现中我们需要访问B的具体成员，因此需要包含头文件，那么我们应该在类A的实现部分（CPP文件）包含类B的头文件而非声明部分（H文件）。
引自 ：http://blog.csdn.net/yang_lang/article/details/6767439
5、修改AfxMessageBox对话框标题
AfxMessageBox的对话框标题默认为项目工程的名字，对话框是为了给用户提示相关信息，而面向用户软件名字一般都与项目工程名不一样，例如软件可能是中文名。所以，有时候我们需要使AfxMessageBox弹出的对话框的标题为当前的软件名。
解决办法：在资源视图中找到String Table并打开，修改ID为AFX_IDS_APP_TITLE的标题为自己想要的值就可以了。
注意：
当你打开String Table并没有看到AFX_IDS_APP_TITLE这一项，因此需要手动添加这一项。
1 右键新建字符串：
2 双击新建的字符串ID，改为AFX_IDS_APP_TITLE：
引自：http://blog.csdn.net/dezhihuang/article/details/52085774
6、VC中如何打开Com10及以上的串口
今天用以前的一个串口程序，发现串口怎么也打不开。因为用的串口不是常规的COM1、COM2而是大于Com10的端口，想着是很简单的增加几个选项就可以轻松搞定的，结果加上后测试，发现总是初始化失败，调试发现在CreateFile里总是失败，找到MSDN一看果然这里有区别。
Win32 API函数CreateFile()除了可打开普通文件外，还可以打开设备，比如可用于打开串口，获得串口句柄。使用CreateFile()函数打开串口时文件共享模式应设置为0（表示独占），创建参数设置为OPEN_EXISTING，模板必须设置为NULL。
如果为COM1至COM9，可使用“COM1”-“COM9”作为文件名传递给CreateFile()函数，函数可成功返回。但是，如果操作对象为COM10及以上的端口，以此方式命名文件名调用CreateFile()函数会返回INVALID_HANDLE_VALUE，表示端口无法打开。
产生这种奇怪现象的原因是：微软预定义的标准设备中含有“COM1”-“COM9”。所以，“COM1”-“COM9”作为文件名传递给函数时操作系统会自动地将之解析为相应的设备。但对于COM10及以上的串口，“COM10”之类的文件名系统只视之为一般意义上的文件，而非串行设备。
为了增加对COM10及以上串行端口的支持，微软规定，如果要访问这样的设备，应使用这样的文件名（以COM10为例）：\\.COM10
所以，对于COM10及以上的串口，CreateFile()的调用样式应调整如下：
CreateFile( "\\\\.\\COM10", // 定义串口名 fdwAccess, // 存取模式（读写） 0, // 共享模式：必须设置为0，表示设备独占使用 NULL, // 保密性
OPEN_EXISTING, // 必须设置为OPEN_EXISTING
0, // 文件属性，如果是异步模式，可设置为
NULL // 模版，串口设备必须设置为NULL
);
这种方式也可以打开COM1~COM9的串口。
引自:http://blog.csdn.net/playboy1/article/details/48316263