WINCE的编程忠告

//========================================================================
//TITLE:
//    WINCE的编程忠告
//AUTHOR:
//    norains
//DATE:
//    第一版:Wednesday  7-March -2007
//    修正版:Tuesday 7-October-2007
//
//========================================================================

1.尽量采用SDK!
 
  我不是那种偏执狂,全盘否定MFC,我也不是不知道MFC编写代码的便利,但我更知道,WINCE下的MFC,必须依赖于Explorer存在--恩,至少在WinCE 4.2下的确是如此.WinCE6.0呢?噢,对不起,我没试过,不知道.
 
  WinCE的可定制性,无法确保每一个OEM厂商一定采用Explore,也许他们会觉得Explorer太大了,又或许他们觉得自己写的shell更漂亮,但不管怎么说,Explorer是在他们的机器上小时了.如果你能想让你的程序能够在他们乃至大部分机器上耀武扬威,那么,请直接采用SDK书写代码吧!
 
 
 
2.不要在代码中出现奇怪的数字!
 
  奇怪的是数字?噢?什么是奇怪的数?
 
  我们来看看有段代码:
 
  TCHAR szFileRead[200] = {0};
  ...
  TCHAR szFileWrite[200] = {0};
 
  恩,现在看起来似乎没什么问题.但我们不妨考虑一下,时间这么一天天过去,很久很久以后,我们突然发现,szFileRead的200空间不够用了,需要扩充成300乃至更多.好吧,那我们就改吧: 
 
  TCHAR szFileRead[300] = {0};
 
  噢,等等,为什么szFileWrite也是200,这个200和之前的szFileRead有没有联系?是否改了szFileRead也需要顺道更改szFileWrite?我的天,这是很久很久以前的事情,我怎么会知道呢?如果有文档记录,翻翻找找,也许尚存一线蛛丝马迹;如果没有呢,那我是不是已经点燃了一个定时炸弹?
 
  与其如此的担惊受怕,我们何必一开始不这么做呢?
 
  #define BUFFER_LENGTH  200
  TCHAR szFileRead[BUFFER_LENGTH] = {0};
  ...
  TCHAR szFileWrite[BUFFER_LENGTH] = {0};
 
  恩,这下子我们知道szFileRead和szFileWrite有那么紧密的联系了.即使以后修改,我们也不用每个每个逐字修正,只要更改BUFFER_LENGTH的定义就可以,这不是非常轻松愉快?
 
 
 
3.字符串?用宏定义的!

  回想一下,如果我们给某个窗口设置标题,是不是会这样:
 
  SetWindowText(hWnd,L"New_Wnd");
 
  是的,没错,这段代码在WinCE下运行得非常完美.但突然有那么一天,你的BOSS心血来潮,让你将该程序一直到WinXP,或是突然你觉得这段代码非常有用,想在WinXP下也秀一把,于是你无非这么做:复制 -> 黏贴 ->编译! Oh,我的上帝!瞧瞧,发现了什么?编译器无法通过!因为在VC6.0下,SetWindowText()的字符不能是宽字符!也就是说,代码应该换成这个模样:
 
  SetWindowText(hWnd,"New_Wnd");
 
  修正一下,终于顺利编译通过.好的,如果你的代码中只有一处,似乎更改一下并没有什么琐屑和烦恼,但想象一下,如果你定义了很多字符串操作:
 
  wchar_t szName[] = L"你好";
  wchar_t szNameAgain[sizeof(szName)];
  wcscpy(szNameAgain,szName);
 
  如果要把这段代码一直到WinXP,需要将wchar_t换成char,wcscpy置换为strcpy.啊,是不是非常烦琐?!万一更恐怖些,这种代码有上千行,那岂不是需要更改得头晕眼花?
 
  当然了,如果不想这么复杂,微软也给我们安排好了后路:
 
  TCHAR szName[] = TEXT("你好");
  TCHAR szNameAgain[sizeof(szName)];
  _tcscpy(szNameAgain,szName);
 
  这段代码无论在EVC或是VC6.0,编译器都会给你一个非常愉快的感受:EVC下TCHAR会自动转换为UNICODE字符,而VC下则不会.
 
  你能确保你的代码永远只能在WinCE下运行么?如果不能,当涉及到字符串的操作的时候,请使用微软为我们安排好的套餐吧!
 
  当然,这也有例外,如果你明确知道所使用的字符串无论在WinCE或是WinXP都是同样的类型,那么,请大胆的使用该类型吧.
 
  比如,最典型的例子,RS-232操作的某些蓝牙通信模块,它发回来的数据永远是ASCII码.如果此时,你是定义TCHAR来接收,在WinXP下工作得非常舒服,但WinCE下可能就会让你脑袋崩溃(原因请见之前的一句话)!这时候,你也只有唯一的选择,接收缓冲区毫不犹豫定义为:char!

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/norains/archive/2007/03/07/1523714.aspx