使用VC++6.0时遇到了麻烦

B08100233 2010-01-20 12:13:13
经常遇到这样的问题：
写好C程序后，Compile会出现Compiling...，程序停在那里就像死机一样；同样，Build会出现Linking...，Stop Build无响应。请问，这是怎么回事？
...全文
65 4 打赏 收藏 转发到动态 举报
写回复
用AI写文章
4 条回复
切换为时间正序
请发表友善的回复…
发表回复
macrojj 2010-01-20
  • 打赏
  • 举报
 回复
一定要vc6.0?
jixingzhong 2010-01-20
  • 打赏
  • 举报
 回复
试试进程重启，rebuild

如果是vc异常，重新安装吧···
anxiang_shuying 2010-01-20
  • 打赏
  • 举报
 回复
不知道啦 我的也会 我是直接关掉 再重新来
nightload 2010-01-20
  • 打赏
  • 举报
 回复
SP6打上也会出现这样的问题，本人用的时候也这样，还会莫名其妙的代码没了。后来放弃之。。。
VC++6.0核心编程源码.rar
第一部分 程序员必读 第一章 对程序错误的处理 在我们开始介绍Microsoft Windows应该提供的许多特性之前，我们首先必须了解Windows的各个函数是如何进行错误处理的。 当你调用一个Windows函数时，它首先要检验你传递给它的的各个参数的有效性，然后再设法执行它的任务。如果你传递了一个无效参数，或者由于某种原因它无法执行这项操作，那么该函数就会返回一个值，指明该函数在某种程度上运行失败了。表1-1列出了大多数Windows函数使用的数据类型的返回值。 表1-1 Windows函数常用的返回值类型 数据类型 表示失败的值 VOID 该函数的运行不可能失败。Windows函数的返回值类型很少 是VOID。 BOLL 如果函数运行失败，那么返回值是0，否则返回的是非0值。最 好对返回值进行测试，以确定它是0还是非0。如果它是TRUE ，则不要测试返回值。 HANDLE 如果函数运行失败，则返回值通常是NULL，否则返回值为 HANDLE，，用于标识你可以操作的一个对象。对于这个返回 值，你应该小心处理，因为有些函数会返回一个句柄 值INVALID_HANDLE_VALUE，它被定义为-1。该函数的 Platform SDK资料将会清楚地说明该函数是返回NULL还 是INVALID_HANDLE_VALID，以便指明函数运行已经失败。 PVOID 如果函数运行失败，则返回值是NULL，否则返回PVOID，以 标识数据块的内存地址。 LONG/DWORD 这是个难以处理的值。返回数量的函数通常返回LONG 或DWORD。如果由于某种原因，函数无法对你想要进行计数 的对象进行计数，那么该函数通常返回0或-1（根据该函数而定） 。如果你调用的函数返回了LONG/DWORD，那么请认真阅 读Platform SDK资料，以确保你能正确检查潜在的错误。 当一个Windows函数返回一个错误代码时，它常常可以用来了解函数为什么会运行失败。Microsoft公司编译了一个所有可能的错误代码的列表，并且为每个错误代码分配了一个32位的号码。 从系统内部来讲，当一个Windows函数检测到一个错误时，它会使用一个称为线程本地存储器的机制，将相应的错误代码号码与调用的线程关联起来。（“线程本地存储器”将在第21章中介绍）。这将使线程能够互相独立地运行，而不会影响各自的错误代码。当函数返回给你时，它的返回值就能指明一个错误已经发生。若要确定这是个什么错误，请调用GetLastError函数： 见原书P4的程序（1） 该函数只返回线程的32位错误代码。 当你拥有32位错误代码的号码时，你必须将该号码转换成更有用的某种对象。WinError.h头文件包含了Microsoft公司定义的错误代码的列表。下面我显示了该列表的某些内容，使你能够看到它的大概样子： 见原书P4的程序（2）和P5的程序 你可以看到，每个错误都有3种表示法：即一个消息ID（这是你可以在源代码中使用的一个宏，以便与GetLastError的返回值进行比较），消息文本（对错误的英文描述）和一个号码（你应该避免使用这个号码，而应该使用消息ID）。请记住，我只选择了WinError.h头文件中的很少一部分内容来向你进行展示，整个文件的长度超过21000行。 当Windows函数运行失败时，你应该立即调用GetLastError函数，否则，如果你调用另一个Windows函数，它的值很可能被改写。 说明 GetLastError能返回线程产生的最后一个错误。如果该线程调用的Windows 函数运行成功，那么最后一个错误代码就不被改写，并且不指明运行成功。有少 数Windows函数并不遵循这一规则，并且它会更改最后的错误代码，但是Platform SDK资料通常指明，当函数运行成功时，该函数会更改最后的错误代码。 Windows 98 许多Windows 98的函数实际上是用Microsoft公司的16位Windows 3.1产 品产生的16位代码来实现的。这种比较老的代码并不通过GetLastError之类函 数来报告错误，而且Microsoft公司并没有在Windows 98中修改16位代码，以 支持这种错误处理方式。对于我们来说，这意味着Windows 98中的许多Win32 函数在运行失败时不能设置最后的错误代码。该函数将返回一个值，指明运行失 败，这样你就能够发现该函数确实已经运行失败。但是你无法确定运行失败的原 因。 有些Windows函数之所以能够成功运行，那是若干个原因产生的结果。例如，创建指明的事件内核对象之所以能够取得成功，原因是你实际上创建了该对象，或者是因为已经存在带有相同名字的事件内核对象。你的应用程序必须知道成功的原因。为了将该信息返回给你，Microsoft公司选择使用最后错误代码机制。这样，当某些函数运行成功时，你就能够通过调用GetLadtError函数来确定其他的一些信息。对于具有这种行为特性的函数来说，Platform SDK资料清楚地说明了GetLastError函数可以这样来使用。请参见该资料，以便找出CreateEvent函数的例子。 当你进行调试的时候，我发现监控线程的最后错误代码是非常有用的。在Microsoft Visual studio 6.0中，Microsoft的调试程序支持一个非常有用的特性，即你可以配置Watch窗口，以便始终都能向你显示线程的最后错误代码的号码和该错误的英文描述。通过选定Watch窗口中的一行，并键入“@err,hr",你就能够做到这一点。观察图1-1，你会看到我已经调用了CreateFile函数。该函数返回INVALID_HANDLE_VALUE（-1）的HANDLE，表示它未能打开指定的文件。但是Watch窗口向我们显示最后错误代码（即如果我调用GetLastErro函数，该函数返回的错误代码）是0x00000002。该Watch窗口又进一步指明错误代码2是指“系统不能找到指定的文件。”你会发现它与WinError.h头文件中的错误代码2所指的字符串是相同的。 图1-1 在Visual Studio 6.0的Watch窗口中键入 “@err,hr"，你就可以查看当前线程的最后错误代码。 Visual studio还配有一个小的实用程序，称为Error Lookup。你可以使用Error Lookup将错误代码的号码转换成它的文本描述。 见P7的Error Lookup插图 如果我在我编写的应用程序中发现一个错误，我可能想要向用户显示该错误的文本描述。Windows提供了一个函数，可以将错误代码转换成它的文本描述。该函数称为FormatMessage。请看下面的代码： 见原书P8的程序（1） FormatMessage函数的功能实际上是非常丰富的，在创建向用户显示的字符串信息时，它是人们首选的函数。该函数之所以有这样大的作用，原因之一是它很容易用多种语言来进行操作。该函数能够检测出用户首选的语言（在Regional Settings Control Panel小应用程序中设定），并返回相应的文本。当然，你首先必须自己转换字符串，然后将已转换的消息表资源嵌入你的.exe文件或DLL模块，不过，这时该函数会选定正确的嵌入对象。ErrorShow示例应用程序（本章后面将加以介绍）展示了如何调用该函数，以便将Microsoft公司定义的错误代码转换成它的文本描述。 有些人常常问我，Microsoft公司是否建立了一个主控列表，以显示每个Windows函数可能返回的所有错误代码。可惜，答案是没有这样的列表，而且Microsoft公司将永远不会建立这样的一个列表。因为在创建系统的新版本时，建立和维护该列表实在太困难了。 建立这样一个列表时存在的问题是，你可以调用一个Windows函数，但是该函数能够在内部调用另一个函数，而这另一个函数又可以调用另一个函数，如此类推。由于各种不同的原因，这些函数中的任何一个函数都可能运行失败。有时，当一个函数运行失败时，较高级的函数对它进行恢复，并且仍然可以执行你想执行的操作。为了创建该主控列表，Microsoft公司必须跟踪每个函数的运行路径，并建立所有可能的错误代码的列表。这项工作很困难。当创建系统的新版本时，这些函数的运行路径就会改变。 1.1 你也能够定义自己的错误代码 好了，我已经说明Windows函数是如何向函数的调用者指明发生的错误。Microsoft公司也使你能够将该机制用于你自己的函数。比如说，你编写了一个你希望其他人调用的函数。你的函数可能因为这样或那样的原因而运行失败，你必须向函数的调用者说明它已经运行失败。 若要指明函数运行失败，你只需要设定线程的最后的错误代码，然后让你的函数返回FALSE，INVALID_HANDLE_VALUE，NULL，或者返回任何合适的信息。若要设定线程的最后错误代码，你只需要调用下面的代码： 见原书P8的程序（2） 请将你认为合适的任何32位号码传递给该函数。我设法使用WinError.h中已经存在的代码，只要该代码能够正确地指明我想要报告的错误即可。如果你认为WinError.h中的任何代码都不能正确地反映该错误的性质，那么你可以创建你自己的代码。错误代码是个32位的数字，它可以划分成下表所示的各个域。 位 31-30 29 28 27-16 15-0 内容 严重性 Microsoft/ 保留 设备代码 异常代码 客户 含义 0=成功 0=Microsoft 必须是0 由Microsoft 由Microsoft/ 1=供参考 公司定义的 公司定义 客户定义 2=警告 代码 3=错误 1=客户定义 的代码 这些域将在第24章中详细讲述。现在，你需要知道的重要域是第29位的信息。Microsoft公司规定，他们建立的所有错误代码的这个信息位均使用0。如果你创建自己的错误代码，你必须在这个信息位中输入1。这样，就可以确保你的错误代码与Microsoft公司目前或者将来定义的错误代码不会发生冲突， 1.2 ErrorShow示例应用程序 ErrorShow应用程序“01 ErrorShow.exe"(在图1-2中列出)展示了如何获取错误代码的文本描述的方法。该应用程序的源代码和资源文件位于本书所附光盘上的01-ErrorShow目录下。一般来说，该应用程序用于显示调试程序的Watch窗口和Error Lookup程序是如何运行的。当你启动该程序时，就会出现下面这个窗口。 见原书P9的插图 你可以将任何错误代码键入该编辑控件。当你单击Look Up按钮时，在底部的滚动窗口中就会显示该错误的文本描述。该应用程序唯一令人感兴趣的特性是如何调用FormatMessage函数。下面是我使用该函数的方法： 见原书P10的程序（1） 第一个代码行用于从编辑控件中检索错误代码的号码。然后，建立一个内存块的句柄并将它初始化为NULL。FormatMessage函数在内部对内存块进行分配，并将它的句柄返回给我们。 当调用FormatMessage函数时，我传递了FORMAT_MESSAGE_FROM_SYSTEM标志。该标志告诉FormatMessage函数，我们想要系统定义的错误代码的字符串。我还传递了FORMAT_MESSAGE_ALLOCATE_BUFFER标志，告诉该函数为错误代码的文本描述分配足够大的内存块。该内存块的句柄将在hlocal变量中返回。第三个参数指明我们想要查找的错误代码的号码，第四个参数指明我们想要文本描述使用什么语言。 如果FormatMessage函数运行成功，那么错误代码的文本描述就位于内存块中，我将它拷贝到对话框底部的滚动窗口中。如果FormatMesage函数运行失败，我设法查看NetMsg.dll模块中的消息代码，以了解该错误是否与网络有关。使用NetMsg.dll模块的句柄，我再次调用FormatMessage函数。你会看到，每个DLL（或.exe）都有它自己的一组错误代码，你可以使用Message Compiler（MC.exe）将这组错误代码添加给该模块，并将一个资源添加给该模块。这就是Visual Studio的Error Lookup工具允许你用Modules对话框进行的操作。 图1-2 ErrorShow示例应用程序 见原书P11—16 第2章 UNICODE 随着Microsoft公司的Windows操作系统在全世界日益广泛的流行，对于我们这些软件开发人员来说，将我们的目标瞄准国际上的各个不同市场，已经成为一个越来越重要的问题。美国的软件版本比国际版本提前6个月推向市场，这曾经是个司空见惯的现象。但是，由于各国对Windows操作系统提供了越来越多的支持，因此就更加容易为国际市场生产各种应用软件，从而缩短了软件的美国版本与国际版本推出的时间间隔。 Windows操作系统始终不逾地提供各种支持，以帮助软件开发人员进行应用程序的本地化工作。应用软件可以从各种不同的函数中获得特定国家的信息，并可观察控制面板的设置，以确定用户的首选项。Windows甚至支持不同的字体，以适应我们的应用的需要。 我之所以将这一章放在本书的开头，是因为我考虑到Unicode是开发任何应用程序时要采用的基本步骤。关于Unicode的问题，我在本书的每一章中几乎都要讲到，而且本书中给出的所有示例应用程序都是“用Unicode实现的”。如果你为Microsoft Windows 2000或Microsoft Windows CE开发应用程序，你应该使用Unicode进行开发。如果你为Microsoft Windows 98开发应用程序，你必须对某些问题作出决定。本章也要讲述Windows 98的有关问题。 2.1 字符集 软件的本地化要解决的真正问题，实际上就是如何来处理不同的字符集。多年来，我们许多人一直将文本串作为一系列单字节字符来进行编码，并在结尾处放上一个零。对于我们来说，这已经成了习惯。当我们调用strlen函数时，它在以0结尾的单字节字符数组中返回字符的数目。 问题是，有些文字和书写规则（比如日文中的汉字就是个典型的例子）的字符集中的符号太多了，因此单字节（它提供的符号最多不能超过256个）是根本不敷使用的。为此我们创建了双字节字符集（DBCS），以支持这些文字和书写规则。 2.1.1 单字节与双字节字符集 在双字节字符集中，字符串中的每个字符可以包含一个字节，也可以包含两个字节。例如，日文中的汉字，如果第一个字符在0x81与0x9F之间，或者在0xE0与0xFC之间，那么你就必须观察下一个字节，才能确定字符串中的这个完整的字符。如果要使用双字节字符集，对于程序员来说简直是个很大的难题，因为有些字符只有一个字节宽，而有些字符则是两个字节宽。 如果只是调用strlen函数，那么你无法真正了解字符串中究竟有多少字符，它只能告诉你到达结尾的0之前有多少个字节。ANSI的C运行期库中没有配备相应的函数，使你能够对双字节字符集进行操作。但是，Microsoft Visual C++的运行期库却包含许多函数，如_mbslen,它可以用来操作多字节（既包括单字节也包括双字节）字符串。 为了帮助你对DBCS字符串进行操作，Windows提供了下面的一组帮助函数。 函数 描述 PTSTR CharNext 返回字符串中的下一个字符的地址 （PCTSTR pszCurrentChar）； PTSTR CharPrev 返回字符串中的上一个字符的地址 （PCTSTR pszStart, PCTSTR pszCurrentChar)； BOOL IsDBCSLendByte 如果该字节是DBCS字符的第一个字节，则返 （BYTE bTestChar）； 回TRUE 2.1.2 Unicode：宽字节字符集 Unicode是Apple和Xerox公司于1988年建立的一个技术标准。1991年，成立了一个集团机构负责Unicode的开发和推广应用。该集团由Apple、Compaq、HP、IBM、Microsoft、Oracle、Silicon Graphics、Sybase、Unisys和Xerox等公司组成。（若要了解该集团的全部成员，请通过网址www.Unicode.org查找。）该集团公司负责维护Unicode标准。Unicode的完整描述可以参阅AddisonWesley出版的《Unicode Standard》一书。（该书可以通过网址www.Unicode.org订购。） Unicode提供了一种简单而又一致的表示字符串的方法。Unicode字符串中的所有字符都是16位的字符（两个字节）。它没有专门的字节来指明下一个字节是属于同一个字符的组成部分，还是一个新字符。这意味着你只需要对指针进行递增或递减，就可以遍历字符串中的各个字符。你不再需要调用CharNext,CharPrev和IsDBCSLeadByte之类的函数。 由于Unicode用一个16位的值来表示每个字符，因此总共可以得到65000个字符，这样，它就能够对世界各国的书面文字中的所有字符进行编码。这远远超过了单字节字符集的256个字符的数目。 目前，已经为阿拉伯文、中文拼音、西里尔字母（俄文）、希腊文、西伯莱文、日文、韩文和拉丁文（英文）字母定义了Unicode代码点1。这些字符集中还包含了大量的标点符号、数学符号、技术符号、箭头、装饰标志、区分标志和其他许多字符。如果你将所有这些字母和符号加在一起，总计约达35000个不同的代码点，这样，总计的65000个代码点中，大约还有一半可供将来扩充时使用。 这65536个字符可以分成不同的区域。下面这个表显示了一部分这样的区域以及分配给这些区域的字符。 16位代码 字符 16位代码 字符 0000-007F ASCII 0300-036F 通用区分标志 0080-00FF 拉丁文1字符 0400-04FF 西里尔字母 0100-017F 欧洲拉丁文 0530-058F 亚美尼亚文 0180-01FF 扩充拉丁文 0590-05FF 西伯莱文 0250-02AF 标准拼音 0600-06FF 阿拉伯文 02B0-02FF 修改型字母 0900-097F 梵文 注1． 代码点是指字符集中的一个符号的位置 目前尚未分配的代码点大约还有29000个，不过它们是保留供将来使用的。另外，大约有6000个代码点是保留供你个人使用的。 2． 2 为何应该使用Unicode 当你开发应用程序时，你当然应该考虑利用Unicode的优点。即使现在你不打算对你的应用程序进行本地化，开发时将Unicode放在心上，肯定可以简化将来的代码转换工作。此外，Unicode还具备下列功能： * 可以很容易地在不同语言之间进行数据交换 * 使你能够分配支持所有语言的单个二进制.exe文件或DLL文件 * 提高你的应用程序的运行效率（本章后面还要详细介绍） 2．3 Windows 2000与Unicode Windows 2000是使用Unicode从头进行开发的，用于创建窗口、显示文本、进行字符串操作等的所有核心函数都需要Unicode字符串。如果你调用任何一个Windows函数并给它传递一个ANSI字符串，那么系统首先要将字符串转换成Unicode，然后将Unicode字符串传递给操作系统。如果你希望函数返回ANSI字符串，系统就会首先将Unicode字符串转换成ANSI字符串，然后将结果返回给你的应用程序。所有这些转换操作都是在你看不见的情况下发生的。当然，进行这些字符串的转换需要占用系统的时间和内存开销。 例如，如果你调用CreateWindowEx函数，并传递类名字和窗口标题文本的非Unicode字符串，那么CreateWindowEx必须分配内存块（在你的进程的默认堆中），将非Unicode字符串转换成Unicode字符串，并将结果存储在分配到的内存块中，然后调用Unicode版本的CreateWindowEx函数。 对于用字符串填入缓存的函数来说，系统必须首先将Unicode字符串转换成非Unicode字符串，然后你的应用程序才能处理该字符串。由于系统必须执行所有这些转换操作，因此你的应用程序需要更多的内存，并且运行的速度比较慢。通过从头开始用Unicode来开发应用程序，你就能够使你的应用程序更加有效地运行。 2． 4 Windows 98与Unicode Windows 98不是一种全新的操作系统。它继承了16位Windows操作系统的特性，它不是用来处理Unicode。如果要增加对Unicode的支持，其工作量非常大，因此在该产品的特性列表中没有包括这个支持项目。由于这个原因，Windows 98象它的前任产品一样，几乎都是使用ANSI字符串来进行所有的内部操作的。 你仍然可以编写用于处理Unicode字符和字符串的Windows应用程序，不过，使用Windows函数要难得多。例如，如果你想要调用CreateWindowEx函数并将ANSI字符串传递给它，这个调用的速度非常快，不需要从你进程的默认堆栈中分配缓存，也不需要进行字符串转换。但是，如果你想要调用CreateWindowEx函数并将Unicode字符串传递给它，你就必须明确分配缓存，并调用函数，以便执行从Unicode到ANSI字符串的转换操作。然后你可以调用CreateWindowEx，传递ANSI字符串。当CreateWindowEx函数返回时，你就能释放临时缓存。这比使用Windows 2000上的Unicode要麻烦得多。在本章的后面部分中，我要介绍如何在Windows 98下进行这些转换。 虽然Unicode函数的大多数代码在Windows 98中不起任何作用，但是有少数Unicode函数确实拥有非常有用的实现代码。这些函数是： 见原书的P21 可惜的是，这些函数中有许多函数在Windows 98中会出现各种各样的错误。有些函数无法使用某些字体，有些函数会破坏内存堆栈，有些函数会使打印机驱动程序崩溃，如此等等。如果你要使用这些函数，你必须对它们进行大量的测试。即使这样，你可能仍然无法解决问题。因此你必须向用户说明这些情况。 2． 5 Windows CE与Unicode Windows CE操作系统是为小型设备开发的，这些设备的内存很小，并且不带磁盘存储器。你可能认为，由于Microsoft公司的主要目标是建立一种尽可能小的操作系统，因此它会使用ANSI作为自己的字符集。但是Microsoft公司并不是鼠目寸光。他们懂得，采用Windows CE的设备要在世界各地销售，他们希望降低软件开发成本，这样就能更加容易地开发应用程序。为此，Windows CE本身就是使用Unicode的一种操作系统。 但是，为了使Windows CE尽量做得小一些，Microsoft公司决定完全不支持ANSI Windows函数。因此，如果你要为Windows CE开发应用程序，你必须懂得Unicode，并且在整个应用程序中使用Unicode。 2． 6 需要注意的问题 下面让我们进一步明确一下“Microsoft公司对Unicode支持的情况”： * Windows 2000既支持Unicode，也支持ANSI，因此你可以为它们当中的任何一种开发应用程序 * Windows 98 只支持ANSI，你只能为ANSI开发应用程序 * Windows CE只支持Unicode，你只能为Unicode开发应用程序 虽然Microsoft公司试图让软件开发人员能够非常容易地开发在这3种平台上运行是软件，但是Unicode与ANSI之间的差异使得事情变得困难起来，并且这种差异通常是我遇到的最大的问题之一。请不要误解，Microsoft公司坚定地支持Unicode，并且我也坚决鼓励你使用它。不过你应该懂得，你可能遇到一些问题，需要一定的时间来解决这些问题。我建议你尽可能使用Unicode。如果你运行Windows 98，那么只有在必要时才要转换到ANSI。 不过，还有另一个小问题你应该了解，那就是COM。 2．7 对COM的简单说明 当Microsoft公司将COM从16位Windows转换成Win32时，公司作出了一个决定，即，需要字符串的所有COM接口方法都只能接受Unicode字符串。这是个了不起的决定，因为COM通常用于使不同的组件能够互相之间进行通信，而Unicode则是传递字符串的最佳手段。 如果你为Windows 2000或Windows CE开发应用程序，并且也使用COM，那么你将会如虎添翼。在你的整个源代码中使用Unicode，将使与操作系统进行通信和与COM对象进行通信的操作变成一件轻而易举的事情。 如果你为Windows 98开发应用程序，并且也使用COM，那么你将会遇到一些问题。COM要求你使用Unicode字符串。操作系统的大多数函数要求你使用ANSI字符串。那是多么难办的事情啊！我曾经从事过若干个项目的开发，在这些项目中，我编写了许多代码，仅仅是为了来回进行字符串的转换。 2． 8 如何编写Unicode源代码 Microsoft公司为Unicode设计了Windows API，这样，它可以尽量减少对你的代码的影响。实际上，你可以编写单个源代码文件，以便使用或者不使用Unicode来对它进行编译。你只需要定义两个宏（UNICODE和_UNICODE），就可以修改然后重新编译该源文件。 2． 8.1 C运行期库对Unicode的支持 为了利用Unicode字符串，因此定义了一些数据类型。标准的C头文件String.h已经作了修改，以便定义一个名字为wchar_t的数据类型，它是一个Unicode字符的数据类型： 见原书P23的程序（1） 例如，如果你想要创建一个缓存，用于存放最多为99个字符的Unicode字符串和一个结尾为零的字符，你可以使用下面这个语句： 见原书P23的程序（2） 该语句创建了一个由100个16位值组成的数组。当然，标准的C运行期字符串函数，如strcpy、strchr和strcat等，只能对ANSI字符串进行操作，它们不能正确地处理Unicode字符串。因此，ANSI C也拥有一组补充函数。图2-1显示了一些标准的ANSI C字符串函数，后面是它们的等价Unicode函数。 图2-1 标准的ANSI C字符串函数和它们的等价Unicode函数 见原书P23的程序（3）和P24的程序 请注意，所有的Unicode函数均以wcs开头，wcs是宽字符串的英文缩写。若要调用Unicode函数，只需用前缀wcs来取代任何ANSI字符串函数的前缀str即可。 说明 大多数软件开发人员可能已经不记得这样一个非常重要的问题了，那就 是Microsoft公司提供的C运行期库与ANSI的标准C运行期库是一致的。 ANSI C规定，C运行期库支持Unicode字符和字符串。这意味着你始终都可 以调用C运行期函数，以便对Unicode字符和字符串进行操作，即使你是在 Windows 98上运行，也可以调用这些函数。换句话说，wcscat,wcslen和wcstok 等函数都能够在Windows 98上很好地运行，这些都是你必须关心的操作系统函数。 对于包含了对str函数或wcs函数进行显式调用的代码来说，你无法非常容易地同时为ANSI和Unicode对这些代码进行编译。在本章前面部分的内容中，我说过可以创建同时为ANSI和Unicode进行编译的单个源代码文件。若要建立这种双重功能，你必须包含Tchar.h文件，而不是包含String.h文件。 Tchar.h文件的唯一作用是帮助你创建ANSI/Unicode通用源代码文件。它包含你应该用在源代码中的一组宏，而不应该直接调用str函数或者wcs函数。如果你在编译源代码文件时定义了_UNICODE，这些宏就会引用wcs这组函数。如果你没有定义_UNICODE，那么这些宏将引用str这组宏。 例如，在Tchar.h中有一个宏称为_tcscpy。如果在你包含该头文件时没有定义_UNICODE,那么_tcscpy就会扩展为ANSI的strcpy函数。但是如果定义了_UNICODE,_tcscpy将扩展为Unicode的wcscpy函数。拥有字符串参数的所有C运行期函数都在Tchar.h文件中定义了一个通用宏。如果你使用通用宏，而不是ANSI/Unicode的特定函数名，你就能够顺利地创建可以为ANSI或Unicode进行编译的源代码。 但是，除了使用这些宏之外，还有一些操作你是必须进行的。Tchar.h文件包含了一些其他的宏。 若要定义一个ANSI/Unicode通用的字符串数组，请使用下面的TCHAR数据类型。如果定义了_UNICODE，TCHAR将声明为下面的形式： 见原书P25的程序（1） 如果没有定义_UNICODE，则TCHAR将声明为下面的形式： 见原书P25的程序（2） 使用该数据类型，你可以象下面这样分配一个字符串： 见原书P25的程序（3） 你也可以创建对字符串的指针： 见原书P25的程序（4） 不过上面这行代码存在一个问题。按照默认设置，Microsoft公司的C++编译器能够编译所有的字符串，就象它们是ANSI字符串，而不是Unicode字符串。因此，如果没有定义_UNICODE，该编译器将能正确地编译这一行代码。但是，如果定义了_UNICODE，就会产生一个错误。若要生成一个Unicode字符串而不是ANSI字符串，你必须将该代码行改写为下面的样子： 见原书P25的程序（5） 原义字符串前面的大写字母L，用于告诉编译器该字符串应该作为Unicode字符串来编译。当编译器将字符串置于程序的数据部分中时，它在每个字符之间分散插入零字节。这种变更带来的问题是，现在只有当定义了_UNICODE时，程序才能成功地进行编译。我们需要另一个宏，以便有选择地在原义字符串的前面加上大写字母L。这项工作由_TEXT宏来完成，_TEXT宏也在Tchar.h文件中做了定义。如果定义了_UNICODE，那么_TEXT定义为下面的形式： 见原书P25的程序（6）
VC6.0用CxImage可以将图片保存成各种格式，我已经验证过，很好用，如果不行，可以留言讨论
CxImage类库是一 个优秀的图像操作类库。它可以快捷地存取、显示、转换各种图像。有的读者可能说，有那么多优秀的图形库，如OpenIL,FreeImage, PaintLib等等，它们可谓是功能强大，齐全，没必要用其它的类库。但我要说，这些类库基本上没有免费的，使用这些类库，你要被这样那样的许可协议所 束缚。在这点上，CxImage类库是完全免费的。另外，在使用上述类库时，你会遇到重重麻烦。因为它们大部分是平台无关的，且用C语言写成，有的还夹杂 着基本的C++ wrapper和成堆德编译选项的声明需要你去处理。而CxImage类库在这方面做得很好。还有让我最看好的，就是作者完全公开了源代码。相对于那些封 装好的图形库和GDI+来说，这一点使我们可以进一步学习各种编解码技术，而不再浮于各种技术的表面。 CxImage是一个可以用于MFC 的C++类，可以打开，保存，显示，转换各种格式的图像文件,比如BMP, JPEG, GIF, PNG, TIFF, MNG, ICO, PCX, TGA, WMF, WBMP, JBG, J2K 等格式的文件。可以实现BMPJPG，PNG TIFF格式等等的转换。 既可以实现图像文件的类型转换，也可以实现在内存图像数据的类型转换，并且使用很方便。
PyQt5快速开发串口工具
本人大学时期的时候，曾经为了学习上位机，花了一暑假死磕了VC++6.0的上位机开发教程，一点一点的敲图书馆借的VC++相关书籍，后来并没有真正运用在实际项目上，颇为可惜；此外，工作以来，有一次，领导紧急受命，...
基于S3C2440的液晶显示器件光电参数检测接口电路
介绍了一种基于S3C2440的液晶显示器件光电参数检测接口电路系统，该系统使用VC++6.0编写上位机，能检测市面上常用的各种型号液晶显示器件光电参数，无需因型号的不同而更换更多的其他驱动电源和驱动信号源等设备，并把有效数据通过通信接口传送到PC中，解决了液晶显示器件在光电参数的检测中遇到的设备仪器频繁更换与接线复杂等麻烦。结果表明，该系统具有工作稳定、操作方便、接线简单、采集数据的精度高等优点。
皮肤控件研究文档，破解后的库文件，皮肤设计工具使用教程
皮肤控件研究文档，破解后的库文件，皮肤设计工具使用教程 皮肤控件 skin++ skincrafter SkinFeature IrisSkin 我共享的都是本人实际验证过的精品,有文档，破解后的库文件，皮肤设计工具使用教程， 1 软件界面 每个软件都要有自己的软件界面，对于软件开发来说，软件界面不一定是最重要的，但是也是相当重要的。一款软件要是可 以在界面上做好，吸引了客户的眼球，那这款软件也就相对成功了一半。 现在各行各业的软件都添加了自己的皮肤色彩，显示出了不同的特点。例如QQ，MSN，Foxmail等等，这些软件都修改 了自己软件的界面，将自己的界面化做的很完善，很漂亮。使用起来感觉很舒服。 2 软件界面的解决方案之一：使用皮肤组件 皮肤组件能完全自动的为您的应用程序添加支持换肤功能，甚至不需要更改您的设计好的Form以及添加一行代码！您 也不再需要花费很多时间来使得自己的应用程序更漂亮。 3 选择皮肤组件产品时需要考虑的几个因素： 3.1 产品易用性 软件控件的API及使用 是否简单易用是我们需要考虑的一个重要关键。这个问题涉及到两个方面：  是否容易整合到现有应用程序中？  是否容易在新的应用程序项目中应用？ 易用性： 界面控件类产品对应用程序的影响应该越小越好，要易于在现有应用程序中整合。这要求API简洁，同时也要求界面库易扩 展，兼容性强。 开发人员能否及时掌握并使用。 3.2 产品稳定性 界面库产品当前的稳定性当然是首要考虑的问题，目前可以从以下几个方面来鉴别产品的稳定性：  是否有足够多的示例Demos来演示控件库产品的各个方面的功能特性  是否已经有众多的成功案例  发布多长时间，同时是否一直有持续更新。 3.3 界面配置灵活性 界面开发一个很重要的问题是界面的样式是非常灵活的。比如一个button上面可能有一个图标，但有时也有可能需 要两个图标；有时有一行文字，但有时也可能有两行不同颜色的文字。界面库产品都需要考虑这些因素。以下是我们在开发 中经常遇到的问题：  控件界面的多样性。 如上面提到的不同位置多个图标，多行文字等。如果一个控件库的button只支持设置一个图标，这显然是不够灵活的，不实 用的。有人可能会说“把几张图片，切图时做到一起不就可以了么，反正一个控件也可以理解只有一个背景。” 如果涉及 到色调调整，这种做法会遇到麻烦，比如如下界面： 其中间图标在色调调整时，其色调不变的。如果图标和背景做到一起，则不能做到此效果。  控件界面元素的动态变化。 控件的界面表现不是静态的，很多情况我们需要能根据程序逻辑动态调整界面表现。 比如： 这种情况在界面设计与开发中是非常常见的，界面库产品需要非常容易的支持此特性。  需要根据程序逻辑自绘界面。 界面库不是万能的，界面库的设计者需要考虑尽可能的避免让客户去绘制界面，但却无法做到100%避免，由于程序逻辑的需 要，客户有时候需要自己绘制控件的某一部分。因此一个完整的界面库系统需要有自绘的支持，即在界面库绘制之后，让客 户有绘制的机会。同时也需要有一套机制来管理自绘部分的图片，颜色等资源，不然无法保证界面色调的一致性。 3.4 界面库高效性 界面库的效率是一个核心问题。糟糕的界面库效率会带来极坏的用户体验，这也应是公司在考虑一个界面控件类产 品时首要考虑的问题。可以通过以下几种方式来判断界面库类产品的效率：  拖拽窗口，观察是否有明显的停顿感。 可在一个系统下，找一些知名软件比较，如QQ/MSN等。如果有明显差异，则说明界面库在界面的绘制等方面存在欠缺。  拖拽窗口，观察界面控件是否有明显闪烁 如发生界面闪烁，则说明界面绘制的处理有些问题。  软件启动速度 界面库产品应该对图片等资源加载做优化，以尽可能的减少界面库加载等带来的时间开销。也可以通过比较软件启动速度来 比较界面库的效率。  软件色调调整时的效率 色调调整等操作一般会涉及到整体界面库的运算与操作，这种情况下也可以显示出不同界面库产品之间的效率差异。如果色 调调整明显带来停顿感，则说明界面库某些方面的效率偏低；一般来说DirectUI类型的库这方面效率会稍微高些。 3.5 周边产品完整性 软件界面开发会涉及到很多部分，通用的界面库产品只是其中的一个需求。界面开发中还会涉及到其他行业相关 的特殊控件、组件需求，如果控件提供商能一站式的解决这些问题，提供完整的界面解决方案，那将极大的减少界面方面的 研发投入。 IM即时聊天客户端产品，除了通用界面库的需求外，可能还需要制作聊天窗口的RichEdit扩展控件，配置面板，系统消息组 件，这些都是一个IM客户端必须的。 3.6 产品升级及售后服务  产品是否有持续的更新和升级 所选择的产品是否有持续的、及时的升级及更新，是否有可靠的售后服务也是需要考虑的重点。 如果控件提供商不能对产品持续投入，则产品不能保持技术竞争力，也不能给客户以信心。一个优秀的产品成长 的过程应该是根据客户的需求及行业的发展来不断升级和完善的过程。  售后服务是否有保障 有保障的售后服务是选择软件产品的基本条件。 一般来说以公司方式运营的产品在售后服务方面更有保障，双方可以以合同或协议的方式来保证产品的售后服务质量及 持续性。 4 市面上有几款比较好的皮肤组件 4.1 Skin++（属于第二代的外挂式的界面库） 网站链接：http://www.uipower.com/index.html 4.1.1 简介：  产品易用性 界面与业务逻辑彻底分离； 支持流行的Windows操作系统; 支持所有Win32/Win64平台，包括.Net应用程序； 　 Skin++ 支持的开发工具: 支持VC++各种版本：VC6，VC2003，VC2005，VC2008; 支持VisualStudio. Net各种版本：VisualStudio. Net 2003, 2005, 2008; 　　 支持 PowerBuilder 各种版本：PowerBuilder 6.0,7.0,8.0,9.0,10.0,10.5,11.0; 　　 支持 Delphi各种版本：Delphi 4，5，6，7，8，2005，2006； 　　 支持C++ Builder 各种版本：C++ Builder 4,5,6,2006;  产品稳定性 成功案例: Skype 华为eSpace 阿里旺旺 淘宝助理 江民杀毒软件 浩方对战平台 360安全卫士（使用DirectUI, DirectUI为上海勇进软件skn++有限公司旗下产品） 等等  界面配置灵活性 可视设计，正式版提供皮肤设计工具SkinBuilder，SkinBuilder是所见即所得的设计开发环境，可以设计用户自己风格的界 面皮肤，并实现动态换肤功能。 没有下载到试验版的SkinBuilder，我联系的skn++的客服人员，只提供了一个视频教程和一个文档Skin++BuilderHelp.chm 视频教程链接地址：http://www.uipower.com/bbs/forum-56-1.html 皮肤设计工具(SkinBuilder)使用演示： http://www.uipower.com/DirectUIBuilder/DirectUIBuilder.html 其它信息：http://www.uipower.com/bbs/index.htm  界面库高效性 下载试用skn++网站上的Skin++ 演示系统 SkinPlusPlus.VS.Net.EvalEdition.3.1.1.exe 窗口数量小于10个时，颜色改变时间延迟不明显，窗口推动不会闪烁。 窗口数量大于30时： 我测试时在MDI应用程序中的主框架下新建100个子窗口，改变一下界面主题颜色，从第一个子窗口改变颜色到整个界面改变 颜色，用了1分27秒。平均一秒一个窗口，内存使用28.4M左右，改变颜色过程中CPU占用99%。颜色改变时间延迟明显，窗口 推动不会闪烁,但是响应速度很慢。  周边产品完整性 可视设计，提供皮肤设计工具，所见即所得的设计开发环境； 　　 色调变换，支持皮肤色调变换，每一套皮肤都拥有N种色调风格； 　　 皮肤资源海量，提供方便的皮肤转换工具，可以将目前主流的皮肤主题转换成Skin++格式； 　　 支持Unicode，提供多种编码格式； 　　 支持静态库链接，与客户程序可以进行无缝整合； 　　 支持第三方控件； 　　  产品升级及售后服务 产品分为：标准版，专业版，企业版，高级版，企业源码版 根据购买的版本的不同服务的项目和时间各异： 提供4到32小时的面对面开发培训 提供1到12个月的免费售后技术服务期 同步升级1个月到12个月  价格：（skin++客服人员提供的价格） skin++ directUI 标准版 价格 5800- 专业版 价格 17800 企业版 价格 38800 58800 高级企业版 价格 58800 88800 企业源码版 价格 98800 控件源码版 价格 158800 平台源码版 价格 218800 4.1.2 详细信息： 链接到<< 皮肤控件:Skin++产品详细信息>> 4.2 DSkinLite 网站链接：http://www.uieasy.cn/ 4.2.1 简介：  产品易用性 DSkinLite界面库API及XML配置语法简单，开发人员一般可以在2-3天内熟悉使用方法。DSkinLite界面库API共20个左右，常 用API函数应该在5左右。同时DSkinLite采用C++编写，专为Visual Studio开发者设计，开发者可以很容易的将DSkinLite整 合到已有软件工程中或者迅速开发新的软件。 DSkinLite使用XML配置界面样式，定义界面资源（字体，颜色，图片）等。借助于XML的灵活的语法，可以描述多 种多样的控件界面风格。因此不管您是否有意选择DSkinLite界面产品，您都可以下载我们的使用试用版，了解DSkinLite界 面库的设计风格，相信会让您了解一种全新的界面产品设计理念，给您的界面开发带来启发。  产品稳定性 近期的客户：长江证券 广州因豪集团 易酷创新 ＩＭ即时聊天类的客户比较多  界面配置灵活性 需要熟悉xml语法。 界面配置灵活。DSkinLite界面库采用XML管理GDI元素，并独创了将界面元素抽象为图片，矩形，线条，文字等元素。任何 一个控件界面均可以由这些元素来组合，使用DSkinLite可以轻松配置各种界面效果。如下图所示: 由此在一个控件界面中，可以灵活的配置界面元素，可以满足绝大多数界面设计需要. 动态的控制界面元素。同时DSkinLite提供相应的API可以控制这些元素（image，text，rect）的显示/隐藏，同时修正某些 属性，如image的picfile属性即更换图片，text的content属性即文本内容。这种界面需求在界面开发中十分常见。  界面库高效性 DSkinLite与其他界面库相比有以下特点： 没有采用Hook所有进程消息的方式，因此没有替换系统相关对话框。DSkinLite 只是采用MFC，ATL等framework类似的方式，简单替换窗口过程，截取界面绘制等消息，对应用程序来说基本上是透明的。 从这个方面讲，DSkinLite是一款轻量级的界面库，界面效率较高。 DSkinLite内部实现跟MFC类似，就是使用SetWindowLong替换窗口过程，然后截获绘制相关消息绘制界面.  周边产品完整性 没有可视化皮肤编辑工具 控件的样式定义于XML中，你可以在xml中定义一张图片，并设置其在窗口的任何位置，包括标题栏区域，  产品升级及售后服务 DSkinLite界面库产品及服务： DSkinLite产品使用授权 软件界面开发服务 控件定制服务 ekRichEdit 控件： ekRichEdit源码版使用授权 RichEdit控件定制服务 DirectUI界面库： DirectU产品源码使用授权 控件定制服务 这个公司的UI设计也是外包的， 有专门针对ＩＭ即时聊天的扩展控件 ekRichEdit;  价格 http://www.uieasy.cn/dskinlite/purchase.html DSkinLite界面库企业版（￥12000） 企业版售后服务如下： 12个月免费Email技术支持 12个月免费版本升级 8小时免费技术培训 两个工作日技术支持响应 软件界面开发服务（￥5000起） 软件界面框架开发服务，根据客户需求及提供的UI设计图片，完成软件界面框架开发。此服务费用为5000元起，具体费用需 要根据用户的需求评估具体工作量来定。 控件定制服务（￥2000起） 如您需要一些特殊的控件，我们可以根据您的需求定制控件。此服务费用为2000元起，具体需要根据控件需求及具体工作量 来定。 4.3 其他产品及信息： 4.3.1 东日IrisSkin 支持Delphi 5/6/7/2005，C++Builder 5/6，BDS 2006，RAD Studio 2007/2009/2010/XE； Microsoft VisualStudio.NET 2002/2003/2005/2008/2010； 含有免费的SkinBuilder工具 IrisSkin 共有两个版本，一个是IrisSkin.dll 用于.Net Framework1.0/1.1 和IrisSkin2.dll 用于.Net Framework2.0版 本。详细内容见安装文件的help文档。 除此之外，东日还有两个很cool的Menu： MatrixMenu和WheelMenu。 (详细内容请参见http://www.sunisoft.cn/irisskin)。 《皮肤控件：东日 Skin详细信息.doc》 4.3.2 Appface Appface支持的语言与开发环境是我见到的最多的，在。net上面使用起来相对前面4中都相对复杂一点， 不过看看那个 Demo也差不多会了，还是几个函数的使用。 (详细内容请参见http://www.appface.net）。 4.3.3 SkinSE 网站链接：http://www.skinse.com/ 是一款真正意义上适合软件界面开发的C++皮肤库。通过使用XML文件来配置GDI资源(如:图片、字体、颜色等)，最大程度将 界面与逻辑分开，让程序员有更多的时间去进行软件内部的逻辑处理。SkinSE没有采用传统的HOOK修改窗口过程函数的方式 ，而是只是针对具体窗口进行界面处理。SkinSE只用到了windows几个底层的核心库，没有用到(MFC/ATL等第三方库)，采用 纯API编写，采用C语言导出方式，增强可移植性。 4.3.4 DotNetSkin DotNetSkin的用法和IrisSkin差不多。此外，网站提供了几个免费的很cool的控件， Button,RadioButton, CheckBox, 那个button和codeproject的XPButton有的一拼了。 (详细内容请参见http://www.dotnetskin.net)。 4.3.5 SkinCrafter SkinCrafter地用法和Skin++有点类似，都是添加一个Com引用，然后加上几句语句用来Load皮肤，和Apply皮肤。另外， SkinCrafter还另外提供了为Windows Installer换肤的软件。 (详细内容请参见http://www.skincrafter.com）。 4.3.6 SkinEngine Alcyonesoft推出了SkinEngine，支持的语言数目与Appface不相上下，用法和Skin++， SkinCrafter类似。（详细内容参 见http://www.ksdev.com) 6、 DotNetMagic提供了许多漂亮的控件（http://www.dotnetmagic.com）, 7、DotNetBar许多很有创意，很炫的控件（http://www.devcomponents.com） 8、Divelements 的许多漂亮的控件（http://www.divelements.co.uk） VclSkin DevExpress系列 XPMenu、 SuiPack、 rainxp、 Flatstyle、 skinengine..... 4.3.7 其他公司的界面库: 金山 自己的界面库; 瑞星 自己的界面库; 腾讯 自己的界面库，皮肤设计工具做的最精细; 迅雷7 自己的皮肤库，采用lua+xml架构，扩展性强，效率高，“万能皮肤库”。
工具平台和程序库

24,855

社区成员

27,343

社区内容

发帖
与我相关
我的任务
社区描述
C/C++ 工具平台和程序库
社区管理员
  • 工具平台和程序库社区
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告
暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章