有关VC++编程的一些经验

编号: 001
时间: 2005-5-19 14:16
说明: 有关不同类型之间的地址运算
部分源代码如下:
typedef struct
{
 BYTE flag;    //0表示始发,1表示反馈
 BYTE content;    //命令内容 
 BYTE hostNum;    //发送方序号
 unsigned short segNum;   //包序号，用于文本发送时
 unsigned short id;   //整个程序中一个包的标识
 unsigned short data_size_extra;  //包后的数据大小
}PACK_CMD;

PACK_CMD * pCmd;

int nOne = (char*)pCmd + 10;
int nTwo = (char*)(pCmd + 10);

问题:nOne是否与nTwo相等?
解答:不会相等.前者在pCmd地址的基础上加上了10字符长度;而后者是加了10个PACK_CMD长度,也就是
     sizeof(PACK_CMD)的长度.
    
编号: 002
时间: 2005-5-19 14:24
说明: 有关VC编译器字节对齐选项对sizeof()函数的影响

问题: 在001中的sizeof(PACK_CMD)会等于9?
解答: 不一定.这跟VC编译器字节对齐选项有很大关系.如果按单字节对齐,其值为等于9;但当按8字节对齐
      时sizeof(PACK_CMD)便等于10了.

编号: 003
时间: 2005-5-24 17:45
说明: 有关串口通信

部分伪代码如下:

void SendComCmd(PACK_CMD cmd)  //把cmd发送给串口控制机
{
 //sending com command
}

void SomeOneBuuton_Click()
{
 PACK_CMD cmd1,cmd2;
 SendComCmd(cmd1);  //某个控制命令
 SendComCmd(cmd2);  //另外一个控制命令
}

问题: 在函数SomeOneBuuton_Click中通信会正常吗?
解答: 在大多数情况都不会正常.目的机(主控机)极有可能收到cmd1还未来得及处理时cmd2命令已经发送过来.
      此时在目的机方看到的情况似乎就是cmd1未收到.因此要在他们之间加上一个延时,延时的时间比所发送
      数据的大小( 0.1毫秒/位 ) 略大一点即可.
      如在此PACK_CMD为10个字节,那么取10毫秒已经足够.

如下的代码便能工作正常:
void SomeOneBuuton_Click()
{
 PACK_CMD cmd1,cmd2;
 SendComCmd(cmd1);  //某个控制命令
 
 Sleep(10);   //延时10个毫秒 
 
 SendComCmd(cmd2);  //另外一个控制命令
}

编号: 004
时间: 2005-5-27 9:07
说明: 有关调试程序

 之前已经把录音程序调试成功,并且经网络发送成功.之后为了可靠,用了轮询机制.下位机每一段时间如10秒
发送一个在线命令过来,上位机会将这个下位机的ID放入一个队列中,上位机每30秒检查这个队列中有无某这个下位机
的ID,有则在线,无则不在线;这时却发现一个录音录的是噪音.为什么?
 1,有可能是录音本身有问题?
 2,录音没问题有可能发送有问题?
 3,学生录音,发送没问题而是上位机接受有问题?写了不应该写的数据?
 4,上位机接的也完全是正确的数据,但发送有问题?
 5,上位机发送的没问题,而是学生机收的数据有问题?
 6,学生机接收的录音数据没问题,可能是因为用播放MP3的设置在播放录音文件?
 按理说应该是这样一个流程,一步步检查下来.这些步骤都没有问题,问题到底出在那里呢?
最后想到上面所说下位机每10秒中发送一个在线命令到上位机.再一想,下位机同时仅能往同一个端口发送数据,在录
录音的时候下位机有没有发送在线命令,发向的是那个端口,于是乎怀疑是下位机把在线命令也发送到上位机录音接收
端口以致噪音.
 之前,我一直在怀疑是上位机的问题,因为在此个过程我将接收和发送录音的数据AX文件重新编译过是不是这
原因致使发送或接收都出现了问题.但一想又不可能,以前在深圳试过都曾试过也没问题.为什么会没问题呢?或许只能
归结于运气很好.比如学生机发送在线命令的时间间隔很长,那么这个时间间隔内,也没有在线命令发送过来,而录音在
在这个时间间隔内停止,然后播放当然没会出现什么问题!因为没有任何的其它不合法的数据进入录音接收端口.
 
 因此我想,当出现类似这样的问题的时候应该多想想现在双方各做了些什么事情,特别是比以前正常工作时多做
了些什么事情!如果仔细想想这个思路,那么这个问题也就不至于查很长时间.

编号: 005
时间: 2005-7-14 11:15
说明: 有关(VC++)调试环境的建立

 今天从网上下载了一些源代码,都是现成的工程!想进行一下单步调试,看看程序是怎么运行的.但总会弹出一个
对话说什么,你所设置的断点无效或者说断点被取消.点击"project"-->"Project Setting"-->"Debug"选项会看到调试
程序为Release版本下的执行文件.我一想可能是由于这个问题,于是想把工作的文件改到Debug文件夹下,而且把产生调
试信息的环境打勾还是不行.反复几次突然发现了"Setting For"选项为release版本,于是改其为debug版本.再试,还是
不能调试.然后我想到了是不是由于下载下来的文件是只读,就是在VC++环境中改了也没什么用.好,就把整个工程所在
的文件夹设置成"文档"属性,可结果还是一样!这就纳闷了,为什么呢?
 再一想,以后有时候出现一些有关环境的问题,都是将那几个配置文件给删除(反正删除再编译的时候也会再生
出来:))不就什么可能解决大多数问题!好就把这些文件(包括*.ncb,*.plg,release文件夹)删除掉,结果就可以调试了.

编号: 006
时间: 2005-7-26 17:30
说明: 有关(VC++)编译环境
 今天需要把同事的程序整理一下,但发现装载到VC++中的时候速度好慢,好半天才把工程打开.根据经验判断有
可能工程的几个配置文件(ncb,opt,aps,clw等)出现问题.于将这个四个文件统统删除掉才试结果还是一样.之后的几次
打开过程跟第一次打开的情况相比,不仅没有大的好转而还经常出现VC++的异常崩溃.于是怀疑是否是自己的VC++环境出
现问题.恢复操作系统,VC++应该没有问题!
 再次试验,还是与之前的情况差不多.
 在仔细观察工程的所有文件的时候发现,有两个资源文件.就想是不是资源文件出现了.并把第二个资源文件打开
打开,内容很少,文件大小也仅1K.或许没有问题!试着把第二个资源文件拿掉看看结果,也没有好的变化.
        当去看第一个RC文件时,很吃惊地的发现RC文件竟然有26M之大.据经验判断,不可能,再大的一个项目有26M的资源
文件似乎很难.再用UltraEdit32进一步打开观察具体内容,发现其中有一个对话框中的MsFlexGrid控件有很大的异样,其中
估计是描述表格的数据出现了大量的"0x000000"等数据.而且这样的数据有25M之多,于是就想当然(感觉)这些数据应该没
有用,而且就是这些数据导致了工程装载速度慢的原因.于将"0x00000"之前的数据COPY下来放一以一个文件中,然后把结尾
部分的有效数据也COPY下来放到这个文件中,以RC后缀命名并替换.再装载应该工程,惊喜出现了:
 能够很快编译工程,并且没有错误!很开心!接受试着使用一下,但发现其中有一个表格发现严重错误立马死去!于是
在工作区去找这个对话框看,发现这个对话框上的表格呈蓝色,并不能显示表格的相关属性.于是决定干脆将这个表格立即删
去!再重新放上一个表格上去,同样的名字,相关的属性也与之前的相同的,再重新编译工程,使用一切正常.

 总结: 碰到类似问题要仔细观察工程的每个文件以决定究竟是哪一部分出现了问题.然后现想办法.对于以上的这个
问题,还有一方法,是直接删除相关对话框上的表格,估计也能解决问题.