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 ...
How to export TeeChart with Unicode characters to PDF?
This option seems doesn't work out of the box.
Region settings for non-Unicode applications doesn't help either.
I have tested it on TeeChart v2015, latest release.
You may try to export the TeeChart content into a TMetaFile, then render it using our Open Source SynPDF library.
The library supports Font-Fallback and Uniscribe, so has good Unicode abilities.
I am trying to update from TeeChart ActiveX 7 to TeeChart 2012/2013. My old TeeChart files were written with a version that saved Unicode strings coded with a "#U#" prefix. I wanted to use the DecodeUTF8String in the new "real-Unicode" version to convert these saved strings to ordinary Unicode strings. However, both the code and decode functions appear to have no effect. Am I missing something? How can I deal with this problem?
Would be great if I could get some help on this!
Being real unicode, these functions don't convert the texts anymore. However, I understand in cases like yours it could still be necessary to do that decodification.
We'll study if we can offer some built-in way to decode the strings coded in older versions. In the meanwhile, the only way I can think on is to manually replace in your TeeChart .tee files (save them as text, not as binary) the coded strings with decoded strings, so you'll have unicode tee files that should be correctly imported in newer TeeChart ActiveX versions.
Delphi 7 and ShellListView it is possible with unicode?
I tried ShellListView, LMD, bsSkinFileListView and TMS Unicode Component. In list i see unicode filenames as i.e.: "????????.txt". Noting works.
Anyone have some idea how to list files/dirs as Windows Explorer with normal visible filenames?
Thanks
Delphi 7 doesn't support Unicode VCL components. You need to upgrade to the latest version of Delphi where all the available shell components have good support for Unicode. Trying to do this in Delphi 7 is simply impractical and nobody is going to invest time doing that nowadays.
I've been able to find a few hex controls by searching online, but none that will compile under Unicode. Does anyone know if there is one available?
Alexey Torgashin's ATBinHex and ATViewer . Did not tried it with unicode delphi versions, but it supports Delphi 2009.
I think that KHexEditor has support for D2009 and D2010, but not tried, I'm currently using D2007...
I think SynEditPlus also has a hex editor control:
http://sourceforge.net/apps/mediawiki/synedit/index.php?title=SynEdit_Home_Page