从 Delphi 2007 升级到 Delphi 2010？
如果我从 2007 年到 2010 年迁移到 Delphi，我应该担心什么？
我已经检查了这篇文章 有很多有趣的东西，但并不完全适合我需要的这次跳跃。
为了澄清我的问题和情况：
- 我有所有 3td 方组件的代码。
- 我需要 unicode，但今年不需要。
- 我需要 win 7 支持 - 主题、表单调整大小问题等。
- 我会很高兴拥有一个像样的帮助系统。
- ADO (dbGO) 是否得到改进？
- 会出现什么令人头痛的情况？
谢谢！
What should I worry about if I move to Delphi 2007 to 2010?
I've checked this article and there was a lot of interesting stuff but not precisely for this jump that I need.
To clarify my question and situation:
- I have all 3td party components' code.
- I will need the unicode, but not this year.
- I need win 7 support - themes, form resize problems and etc.
- I will be happy to have a decent help system.
- Is ADO (dbGO) improved?
- What headache to expect?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
抱歉，Delphi2010的帮助内容比Delphi2007好，但与Delphi7相差甚远。
关于unicode迁移的资源有很多，而且很容易找到。
我只会坚持第三方库，这是困难的部分。
你有源代码，很好，但是考虑修复这些组件内的 unicode 相关问题是非常雄心勃勃的！
我的建议：检查您的第 3 方库的兼容性，检查您的代码兼容性 - 修复所有警告，遵循 CodeGear 的这份优秀白皮书：Delphi 和 Unicode
http://edn.embarcadero.com/article/38980
Sorry for you, the help content of Delphi2010 is better than Delphi2007, but far away from Delphi7.
There are many resources about unicode migration, and it is very easy to find.
I will just insist on 3rd party libs which is the difficult part.
You have the source code, good, but considering fixing unicode relates issue inside these components is very ambitious !
My advice: Check the compatibility of your 3rd party libs, check your code compatibility - fix all warnings, follow this good white paper from CodeGear : Delphi and Unicode
http://edn.embarcadero.com/article/38980
Delphi 2007 中已经有了主题。并不是说 2007 已 100% 为 Win7 做好准备，但主题对于大多数用户来说很重要，所以恕我直言，这不是升级的理由
如果您计划使用 Delphi 2011 并发布您的软件的 Mac 版本，为什么不一步一步地去做，今天就解决 Unicode 问题（？）呢？我不确定答案，只是担心:-) 我正处于这种情况，已经拥有 Delphi 2009 的许可证，但由于 Unicode 的原因仍然未使用，所以我在 2007 年。
You already have themes in Delphi 2007. Not that 2007 is at 100% prepared for Win7 but themes is what important for most users so this is IMHO not argument to upgrate.
If you plan to use Delphi 2011 and release Mac version of your software, why not do it step by step and take Unicode headache (?) today? I am not sure of answer, just worrying :-) I am in this situation, already have license for Delphi 2009 but still unused because of Unicode so I am in 2007.
将 Delphi 7/2007（ansi 字符串）移植到 2009/2010（unicode 字符串）的“初学者”方法是盲目搜索并替换所有出现的 String 并替换为 AnsiString，类似地，盲目地将 Char 的所有实例更改为安西查尔。这很快就会暴露出它是痛苦的、愚蠢的、错误的。因此，受到惩罚的用户（没有阅读由 Nick Hodges 编写的 Embarcadero 发布的过渡指南）将撤退并舔舐伤口，并考虑永远坚持使用 Delphi X（其中 X 位于 [7,2007,myFavouriteVersionHere] 集合中） .
第二种方法是下载您需要的任何组件的已更新版本，并且仅更新您自己确实找不到任何新更新的源代码的组件，然后继续更新您的应用程序代码。
我发现，如果您为了金钱而出售您的应用程序，或者您依赖您的应用程序对您或您的公司有用，那么这样做是值得的。正如您所说，这不仅是升级以处理编译器差异的问题，而且是升级以处理平台差异的问题。不仅是您上面提到的平台差异，还有您没有提到的平台差异，例如 UAC，以及文件和文件夹的用户权限以及其他权限的更改。您的应用程序是否需要能够写入 C:\Program Files 内的文件夹以及其他内容等？这些需要修复。
如果您的应用程序是典型的“泥球”，增量开发，并且没有优雅的面向对象设计，并且如果（这是典型的）您的应用程序甚至没有真正满足 Microsoft 作为 Windows XP 的一部分发布的推荐规范， 2002年，你确实需要奋起直追。
如果这对你来说太过分了，你可以考虑将工作外包出去。专家可能会在几个小时内将应用程序从旧的 delphi 版本移植到新版本，并培训您如何从那时起进行维护。
A "Beginner" approach to Delphi 7/2007 (ansi strings) ports to 2009/2010 (unicode strings) is to blindly search and replace ALL occurrences of String and replace with AnsiString, similarly, blindly changing all instances of Char to AnsiChar. This quickly reveals itself to be painful, and stupid, and wrong. Thus chastened, the user (without reading the transition guides published by Embarcadero, written by Nick Hodges) will retreat and lick their wounds, and consider sticking with Delphi X forever (where X is in the set of [7,2007,myFavouriteVersionHere]).
The second approach is to download already-updated versions of any components you need, and only update the components you really can't find any newly updated source code for, yourself, and then proceed to updating your application code.
I find that it is worth doing this, if you either sell your application for money, or if you rely on your application to be of some usefulness to you, or your company. It is not only a question of upgrading to handle compiler differences, but upgrading, as you say, to handle platform differences. And not only the platform differences that you are mentioning above, but ones you didn't mention, like UAC, and changes in user-permissions on files and folders, and other priveleges. Does your application require the ability to write to folders inside C:\Program Files, and other things, etc? Those need to be fixed.
If your application is a typical "ball of mud", developed incrementally, and without an elegant object oriented design, and if (as is typical) your app doesn't even really meet the recommended specs that Microsoft published as part of Windows XP, in 2002, the you really have some catching up to do.
If it's all too much for you, you could consider contracting the work out. An expert could probably port the application from an old delphi version, to a new one, in a few hours, and train you how to do the maintenance from that point forward.