使用Delphi 7进行开发时,为Delphi 2009做好准备吗？

发布时间：2020-12-15 04:14:50 所属栏目：大数据来源：网络整理

导读：我正在Delphi 7中开发一个Word插件,但很快我会将它升级到Delphi 2010,因为你知道,因为2009版本Delphi引入了新的字符串类型UnicodeString,它等于关键字字符串.另一方面,根据 this thread,我们需要使用WideString与COM通信. 我的问题是,为了在将来开发Delphi 7

我正在Delphi 7中开发一个Word插件,但很快我会将它升级到Delphi 2010,因为你知道,因为2009版本Delphi引入了新的字符串类型UnicodeString,它等于关键字字符串.另一方面,根据 this thread,我们需要使用WideString与COM通信.

我的问题是,为了在将来开发Delphi 7时为Delphi 2010做好准备,我该怎么做？目前在我的代码中我使用了用户定义的类型UnicodeString,其想法是当使用D7编译时我的字符串是WideString,当使用D2009编译它的UnicodeString时,我看到Virtual TreeView使用这样的技术,如下面的代码：

{$ifndef COMPILER_12_UP}
type
  UnicodeString = WideString;
  PByte = PAnsiChar;
{$endif COMPILER_12_UP}

解决方法

步骤1
通常你应该尽可能坚持使用’普通’类型：即String和Char
这样,您的代码将在升级时“自动”转换.
注意：有一些特定于应用程序的例外.

如果你不这样做,你可能会遇到一个问题,我升级了一些代码库,在某些地方使用过AnsiString.当AnsiString = String时,这在旧Delphi中不是问题.但显然,当类型不再相同时,这是有问题的.

第2步
阅读为迁移到Unicode Delphi 2009而提供的指南.它提到了在处理字符串时通常滥用的函数,因为假设每个字符都是1个字节.请注意这些,并根据这些建议编写代码.

步骤3,4和5
避免使用条件编译.你只会给自己带来更多麻烦.

步骤6,7,8,9和10
不要试图通过重新定义其内部类型来猜测编译器.你让自己暴露在许多头痛之中.问题是VCL,运行时库和第三方组件都对String的“理解”有所了解.升级到Delphi 2009时,仍然会分享“新理解”.

如果您更改了该定义,那么由于隐式兼容性,旧版本中的某些内容仍然有效;然而,在德尔福2009年的事情突然发生变化时,可能会有可怕的突破.

记得！使用的字符串类型是Windows API调用的重要考虑因素. Windows通常支持大多数功能的Ansi和Wide版本.在较旧的Delphi中,默认使用Ansi版本;从Delphi 2009开始,默认使用Wide版本.

笔记
关于您在COM开发中对WideString的关注：
较旧版本的Delphi在String和WideString之间提供自动类型转换 – 让编译器尽可能地为您工作.显然你的COM接口必须用WideString声明,但是尽量避免使用它.

编辑
看看Hughes提供的链接：Get ready for Delphi 2009 and up when developing with Delphi 7?

还要强调的是：每个新版本的Delphi都试图保持某种程度的向后兼容性(包括Delphi 2009).如果您只是“正常”编码,那么您不太可能受到任何影响.事实上,反过来通常是正确的;你得到的越多,就越有可能遇到问题.

我搬到新版Delphi时遇到的唯一严重问题是：

>没有源代码的第三方代码/库.>没有维护的第三方代码,他们的开发人员使用各种编码“技巧”.> Delphi 3中的Midas代码是一项特别艰巨的升级. (但同样,开发人员绕过推荐的技术是一个罪魁祸首.)

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!