I have a unit I wrote in Delphi 7 some time ago, and have just had the fun (pain) of converting to Delphi XE (Unicode).
The Unit works fine after some trouble, I am now trying to make this unit compatible with different Delphi Versions should I ever need to switch IDE back to Delphi 7 whilst updating some other code.
I only have Delphi 7 and Delphi XE, but from what I gather code written in Delphi 1 to Delphi 2007 will compile, but code from Delphi 2009 and above will be Unicode.
...Anyway, in the Unit I am separating the non-unicode and unicode like so:
{$IFDEF VER150} //Delphi 7
// code
{$ELSE IFDEF VER220} //Delphi XE
// code
{$ENDIF}
How do I modify the compiler directive so the rules apply to multi versions? For example something like:
{$IFDEF VER80, //D1
VER90, //D2
VER100, //D3
VER120, //D4
VER130, //D5
VER140, //D6
VER150, //D7}
This would then cover all Delphi versions should I distribute the source or .dcu unit.
Thanks.
I wonder if the simplest approach in this instance is to switch behaviour on the UNICODE conditional. This conditional is defined if and only if you are using a Unicode version of Delphi, i.e. in Delphi 2009 and later. The big advantage of this is that it is future proof—you don't need to update your code every time a new Delphi is released. What's more, the conditional switch will be far more readable since it will clearly express the intent.
The Delphi documentation has an excellent topic listing all the pre-defined conditionals. The full list of version conditionals is also linked from there.
Your best bet is actually to look at one of the many JEDI projects, http://sourceforge.net/projects/jedi-apilib/ for example and look at how they do it. They have common include files that contain exactly the details you are interested in. JVCL is another good choice ...
Related
We have large commercial app that we want to convert from Delphi 6 to 2010. Approx 10 3rd party component sets, all with source code... I have heard warnings about Unicode with 2010 - Does anyone have experience and or suggestions?
There are many resources available that you can read and that you will assist in the migration from Delphi 6 to Delphi 2009/2010 (Unicode).
You can use these articles as a guide.
Unicode Migration Statistics Tool (This utility will hopefully assist you in collecting useful statistics
on how hard (or not) it would be to migrate your older applications to
Unicode.)
Delphi 2009 and Unicode
Delphi 2009 strings explained by example
Upgrading a major project to Delphi 2009
Delphi and Unicode
Dr. Bob Delphi 2009 Unicode
Delphi 2009 - Unicode in Type Libraries
On Strings and Unicode in Delphi 2009
Delphi in a Unicode World Part I: What is Unicode, Why do you need it, and How do you work with it in Delphi?
Delphi in a Unicode World Part II: New RTL Features and Classes to Support Unicode
Delphi in a Unicode World Part III: Unicodifying Your Code
CodeRage 4 : Using Unicode and Other Encodings in your Programs
Bye.
You'll find some useful answers in these StackOverflow questions:
Move project from Delphi 3 to Delphi 2010
When and Why Should I Use TStringBuilder?
Convert function to delphi 2009/2010 (unicode)
Unicode problems with Delphi 2009 / 2010 and windows API calls
Also, for what it is worth, I purchased Marco Cantu's Delphi 2009 Handbook. It was all I needed to make a relatively smooth converstion from Delphi 4 to Delphi 2009 in only a few weeks.
I do, however, recommend that you ensure your 3rd party packages have a Delphi 2009 upgrade, or you may have some real difficulties. Converting your own code is one thing. Converting someone else's is another.
I use two 3rd party packages, both with source code. Both had upgrades available, and the developer of one of them wrote that he had a lot of trouble upgrading his very complex component to the Unicode of Delphi 2009. It took him a few months, but he completed it. And as a result, I had little trouble with my implementation of his component when I did my upgrade.
i've been in the same circumstance recently. you mostly need to pay attention to the "edges" of the app. INI files, file I/O, log files, etc. win API calls from delphi work since they've now connected the unicode API calls instead. check each 3rd party component set to make sure they're at least ready for Delphi 2009...better yet 2010. even my use of databases simply wasn't an issue...nearly everything worked right away. it just wasn't a big deal. anything that relies on the size of a character should be reviewed.
really the transition of most concern is 2007_or_earlier --> 2009_or_later.
there are plenty of discussions/blog entries about it. you could read, read, read...or you could get started & see what happens. (i did some of both). i'm sure there are "stack overflow" issues discussing your question. i'm not pretending to give a detailed description of what could happen.
it's simply not as scary as it sounds.
Approx 10 3rd party component sets, all with source code.
One thing I'd add is if the component doesn't support Delphi 2009/2010, don't try to upgrade it by hacking the code.
Following is what I posted on How do the new string types work in Delphi 2009/2010?:
See Delphi and Unicode, a white paper written by Marco Cantù and I guess
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!), written by Joel.
One pitfall is that the default Win32 API call has been mapped to use the W (wide string) version instead of the A (ANSI) version, for example ShellExecuteA If your code is doing tricky pointer code assuming internal layout of AnsiString, it will break. A fallback is to substitute PChar with PAnsiChar, Char with AnsiChar, string with AnsiString, and append A at the end of Win32 API call for that portion of code. After the code actually compiles and runs normally, you could refactor your code to use string (UnicodeString).
I must add this article from Carey Jensen to others mentioned. It is labeled: "Delphi Unicode Migration for Mere Mortals: Stories and Advice from the Front Lines" (in english).
http://www.danysoft.com/free/delphiunicodemigration.pdf
As you can see in the title of it, you will find many experiences and hints and tips. I think it is the answer to your question. After carefully read it, you will sure knows what to do next. :)
Found in: http://www.danysoft.com/productos/migrar-aplicaciones-a-delphi-xe-o-cbuilder-xe.html
Another point to take care of, is the usage of Variant types with strings and the VarType function testing for strings: one needs to use varUString instead of varString.
Assuming AValue is of type Variant and has being assigned a Unicode string value, the following won't work:
if VarType(AValue) = varString then ...
and needs to be changed to
if VarType(AValue) = varUString then ...
In this question (link) it was said that the line below (in each unit) would remove as much RTTI as possible:
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}
The posting didn't mention what Delphi version it works with, but I assume D2010. However, when I include the line above, I get this error:
DCC Fatal Error: E2158 System unit out of date or corrupted:
missing TVisibilityClasses.
I'm using a "stock" version of D2010 and have never done anything that I'm aware of that would change the default installation or the libraries.
Any suggestions? TIA
Related question: link.
Make sure you put the "{$RTTI" line below the "unit unit1;" line.
Note that as of XE5 and newer, this directive needs to be in each individual unit for which you want to disable RTTI. Before that (as in comments, which applies only to XE4 and below) it could be in the DPR file and would apply to all units in the project.
The new RTTI is for Delphi 2010 and up.
It can be removed, but then lots of things will have limited functionality (like JSON conversion, part of DataSnap and many of the newer 3rd party libraries that do ORM or other mappings).
Things depending on TValue are gone anyway.
"old style" RTTI (which was introduced in Delphi 1 and is still present in Delphi 2010) cannot be removed.
So: it is recommended to remove RTTI only from your own units, and not from the RTL and VCL.
--jeroen
This is related to another Delphi-version question but still different;
I'm looking for a way to detect the service-pack (or build number) of the Delphi compiler that's compiling my code. The jedi.inc is nice, but it doesn't tell me the exact version. (I can't use the SUPPORTS_* defines in there either, as those are version-related too)
I need this, because some bugs are present in older versions (in this case, it's a _ValLong bug in Delphi 2009) that's fixed in a later service-pack (Delphi 2009 service pack 3 in this case).
Currently I have all kinds of checks in my code, like this :
{$IFDEF BUG_QC_68123}
But I can't just say this in my main include file :
{$IFDEF DELPHI2009_UP}
{$DEFINE BUG_QC_68123}
{$ENDIF}
...As this would miss the fact that D2009SP3 and later don't have this bug anymore.
Any ideas?
PS: This will probably also apply to older (and newer) versions of Delphi, so any library- and/or component-vendor will have an interest in this too, I presume.
There are symbols defined for each version:
VER80 - Delphi 1
VER90 - Delphi 2
VER100 - Delphi 3
VER120 - Delphi 4
VER130 - Delphi 5
VER140 - Delphi 6
VER150 - Delphi 7
VER160 - Delphi 8
VER170 - Delphi 2005
VER180 - Delphi 2006
VER180 - Delphi 2007
VER185 - Delphi 2007 (Note: symbol VER185, for example, is used to indicate Delphi 2007 compiler or an earlier version.)
VER190 - Delphi 2007 for .NET
VER200 - C++ Builder 2009
VER210 - Delphi 2010
VER220 - Delphi XE
VER230 - Delphi XE2
VER240 - Delphi XE3
VER250 - Delphi XE4
VER260 - Delphi XE5
VER270 - Delphi XE6
VER280 - Delphi XE7
WIN32 - Indicates that the operating environment is the Win32 API.
LINUX - Indicates that the operating environment is Linux
MSWINDOWS - Indicates that the operating environment is the MS Windows/li]
CONSOLE - Indicates that an application is being compiled as a console application
Source
Another source
You can't check for different build numbers.
And for the curious, VER10-VER70 where the turbo pascal versions, and VER110 was a C++ builder version.
Unfortunately, constants like RTLVersion in System.pas aren't updated in updates, but I think it would be a good suggestion if someone wants to make a QC entry for it.
If the bugs you are testing for are practical to reproduce in code, you could always test for them on startup and set your own global flags.
I get around these differences by making sure we always apply the latest updates. I haven't run in to a case yet where an update was unstable and forced me to roll it back. At least not with Delphi.
You could try including the compiler file version in your software. For example, DCC32.exe has a file version on it which you can programmatically get at and then write to a unit as a const. This could be done as part of your build process so it gets the version info before building your app (it'd be very easy to do with something like FinalBuilder).
I've done this for other things so that on our About screen we can get various bits of useful info. Also when we have an error in one our applications, we can bundle this info into our EurekaLog bug reports.
However I don't know if the file version on DCC32.exe is updated with every Delphi update.
The compiler does not expose that information. It only tells you the major version, which doesn't change when updates are applied.
I think the best you can do is to always write code for the latest update. Assume that consumers of your code will also have the latest update. If they don't, then it's their own fault, and not a problem you need to worry about. Mention it in your system requirements. Sure, your code won't work for them, but neither will anyone else's because they're still using known-bad code.
The next-best alternative is to write assuming that no updates have been applied. That is, write your code as though all known bugs are still present. The downside is that your code probably won't run as well as it otherwise could, so everyone who did the right thing by upgrading gets punished by continuing to have your suboptimal code.
It is possible to work with a Delphi 5 project in the Delphi 2009 IDE by referencing the Delphi 5 version of dcc32?
If so are there any issues to watch out for concerning the way that project settings (search paths, conditional defines etc.) are implemented in 2009?
Edit: Just to clarify I am also upgrading the project to Unicode but will still need to debug and run releases in the old configuration
It depends on what you're trying to accomplish and what limitations you are willing to accept.
As far as I know, you can't use the Delphi 2009 IDE to maintain Delphi 5 projects directly. For example, even if you stick to functionality that's common between the two, some properties that are not supported in Delphi 5 are written to your DFMs, causing an error at run time.
I've maintained projects and library code that were written in Delphi 2005/2006/2007 that was also being used in Delphi 6/7. I usually edited and debugged these using the latest IDE. I had separate project files for each target version and made sure they all used the same memory manager. Finally, I had an automated build process and unit tests that would strip incompatible properties out of the DFMs (my own DFM Scrubber), make sure all of the targets always compile and run unit tests, which are also recompiled for each target.
All in all, it's more effort and I wouldn't recommend it unless you have a specific requirement to do so.
No. That said, it is still Delphi, and assuming you have source or D2009 versions of any custom components it can be modified to compile in Delphi 2009. The layout of the VCL has changed quite a bit since D5, so expect to have to modify your uses clauses and probably rewrite some small chunks here and there, but it is doable.
You either port your code to Delphi 2009/2010 level (Unicode), or you may as well not install the product.
I suggest you open the project and see where it fails, close the project (without saving anything), find the component versions you need and install them, and once the project opens up in design mode (all components are installed) you can start porting.
Read the Unicode Delphi migration (porting) information available at the website.
Ask your self each time you see PChar, and Char, if it needs to be PAnsiChar, or AnsiChar instead? If you are reading bytes from a disk, a com port, or a network connection, you will need to change from Char to AnsiChar, from PChar to PAnsiChar, otherwise, you might just leave the Char and PChar as they are and they will become Unicode. Always be aware that Char is not a Byte, anymore.
You also must replace explicit references to narrow Win32 API calls with versions without the A (ansi) suffix. Example: CreateFileA might need to become just CreateFile.
W
I have a rather large (freeware) project written with Delphi 2007 which is using both the TntUnicodeControls and the TntLXControls library and I'm planning to move to Delphi 2009.
Unfortunately I'm using those libraries everywhere in my project:
Replacement for VCL controls to provide Unicode capability
Win32 API wrappers (mostly for comparing strings)
The feature enhancements of TntLXForms, TntLXRegistry, ...
Third-party components which use TntControls. (VirtualTrees, SpTBXLib, updates for D2009 are available)
Do you have any experience and/or suggestions in porting such a project to Delphi 2009. Is it advisable to first switch to the (commercial) TMS Unicode controls?
Install GExperts; there is "Replace component" IDE addin that can help converting TTntXXX to TXXXX controls. Try for once, and if it's ok just check "Replace evrywhere in project".
SpTbx and VirtualTrees can only be recompiled - they both support D2009.
If you used WinAPI wrappers just to call Unicode API-s they should work in D2009 also.
That leaves you with TntLX controls (TntLXForms, TntLXRegistry, ...). Since they are unsupported, may be it is good time to change them anyway.
I can help with some of this, as I'm porting a C++Builder application that uses TNT from 2007 to 2009. The switch to Unicode in D2009 is overdue and welcome. However, it's unfortunate that the transition is probably easier for those who have NOT needed unicode in the past, and probably still don't. If, like me, you needed Unicode and used Troy Wolbrink's great TNT control to provide it, you have a rather more complex job...
The good news is that there's a new version of TNTControls from TMS Software which supports D2009. I haven't looked at this, but expect it is just a 'facade' layer over the native VCL components to ease portability. I'd consider that if your other libraries can be rebuilt to use it.
However, you may be better going back to native VCL controls, and the reason is string types. TNT control have always used WideString to pass Unicode strings back and forth, and you may well have WideString use scattered through your own code. This will work, but it's not ideal as WideString should really just be used for COM interop as it 'wraps' the COM BSTR type. Native unicode strings in D2009 are reference-counted and should be significantly faster.
If you do decide to replace TNT components with native VCL ones, you can use GExperts "Replace Components" command - or, maybe easier, do a search and replace in your .DFM and .PAS files (which you DO have in text form, don't you) to replace TTNT with T.
I recommend the following resources:
Marco Cantu's Delphi 2009 Handbook Chapter 3 (Porting to unicode)
http://www.marcocantu.com/dh2009/
Nick Hodges' articles (Delphi in a Unicode World)
http://blogs.codegear.com/nickhodges/2008/11/20/39149
I think either way it's going to be a lot of work. Probably more so than if you hadn't done all the work to make it unicode compatible before. I personally would forget about the tms Unicode controls, and go back to the vcl. It will save more pain in the future. (nothing against those controls, mind you.)
Also remember, that D2009's string, is not the same thing as D2007's Widestring which you have undoubtedly used in your app. So all instances of Widestring, which you so diligently changed from string (which was AnsiString), need to go back again to string(which is now unicodestring).