The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Unicode support in Delphi?

Delphi 7 + SQL Server 2000.

My client asked me about this. A large (well over 100 form) project + 300+ units. Currently sold into a US/westerncentric market.

So far it seems like a ton of case by case eyeballing of the source code. I personally think it needs to wait until we have customer work to fund it.

War & peacetime stories appreciated.
Bored Bystander Send private email
Saturday, September 10, 2005
 
 
Donald Adams
Saturday, September 10, 2005
 
 
Never used but this is the unicode component library I hear mentioned most often:

http://www.tntware.com/delphicontrols/unicode/
Herbert Sitz Send private email
Saturday, September 10, 2005
 
 
Thanks, guys. But these links seem to verify what I expected: Delphi's supplied VCL, by default, expects to work only with ANSI 8 bit character sets. So it will be a major piece of surgery to retrofit unicode to this project.
Bored Bystander Send private email
Saturday, September 10, 2005
 
 
Yes, unicode support in Win32 Delphi is a sore issue.

As one other option, you might think about porting to Delphi.NET and using VCL.NET.  Delphi.NET supports unicode because support for it is part of .NET itself.

Depending on how your application is written the port form Win32 VCL to VCL.NET could be fairly smooth.  This would mean: (1) original app should use mostly just Borland VCL controls, or 3rd party components that have VCL.NET versions, and (2) code avoids non-.NET-friendly things like pointers, certain typecasts, etc.  I believe there is a compiler switch that enables you to generate output list of lines in your Delphi code that will not work in the managed .NET environment.  If there's not much of that the port might be easier than you'd expect.
Herbert Sitz Send private email
Sunday, September 11, 2005
 
 
Since TNT descends from VCL, is it posssible to use simple search and replace to exchange all instances of TEdit with TTNTEdit, TComboBox with TTNTComboBox, etc in your text-based DFMs?
Matt Foley
Sunday, September 11, 2005
 
 
The TNT controls are used extensively throughout Float's Mobile Agent, the open-source Sony-Ericsson phone management software.  Very nice piece of software.

http://fma.sourceforge.net/
Matt Foley
Sunday, September 11, 2005
 
 
Bored Bystander > But these links seem to verify what I expected: Delphi's supplied VCL, by default, expects to work only with ANSI 8 bit character sets. So it will be a major piece of surgery to retrofit unicode to this project.

Yes. So major that you'll have to move on to Delphi.Net if you want full, native support for Unicode. As far as I know, the Win32 version of VCL's don't support Unicode. I assume that Borland didn't have a big enough market share in Asia to make it worth retrofiting Unicode in its development tools.
Fred
Sunday, September 11, 2005
 
 
Guys, again, thanks. Yeah, I have mentioned Delphi .Net as a solution. That seams like the most seamless way to go about this.
Bored Bystander Send private email
Sunday, September 11, 2005
 
 
"Since TNT descends from VCL, is it posssible to use simple search and replace to exchange all instances of TEdit with TTNTEdit, TComboBox with TTNTComboBox, etc in your text-based DFMs?"

I'm sure that's possible.  But that only gets you to the point where your edit controls support unicode (and assumes that only edit controls you're using are the standard ones in Borland VCL). 

The larger problem would be revising all of the code where you're processing string values.  All 'string' declarations would have to be redeclared as 'widestring', and any string functions in expressions would have to be changed to use functions that are unicode compatible.  It looks like the Delphi Fundamentals project has a set of replacement functions (http://fundementals.sourceforge.net/unicode.html ).  Even assuming those functions work as good replacements, the whole process of going through a large Win32 app and unicode enabling the behind-the-scene string processing seems non-trivial.

Or am I missing something?
Herbert Sitz Send private email
Sunday, September 11, 2005
 
 
Herbert, that's exactly the way I see it. A lengthy and tedious process of "human code filtration". String to WideString itself is relatively straightforward, but also conversion of all database fields, and replacement of all VCL components. Plus we use InfoPower, which inherits from the built-in VCL.
Bored Bystander Send private email
Sunday, September 11, 2005
 
 
What are you guys talking about? Delphi 7 has WideString. It doesn't only work with ANSI character sets, and anyway the ANSI support is not just 8 bit either, its also multi-byte for Far Eastern sets. I am a C++ not a Delphi programmer but I recently had to work in Delphi 7 with Unicode extensively. You should give more particulars about your requirements, but accessing SQL Server should not be such a big deal. If you have GUI Unicode (multilingual) requirements then yes, you will need to get into Tnt controls or look into VCL.Net (Delphi 2005).
Anon and anon
Sunday, September 11, 2005
 
 
TNT Unicode works fine. I support Chinese, Japanese & Korean with that library. It comes with extensive Unicode library functions as well and has Unicode DBgrids, Unicode INIfiles etc. A simple search & replace with GExperts will do, and some rewriting of the sting-part of the code (but that can be minimized by doing some strategic UTF8 to Widestring and vice versa converting).

True, Delphi out-of-the-box does not support Unicode in the VCL, but Troy Wolbrink has done a helluva job with his drop-in replacement.
Frank de Groot Send private email
Monday, September 12, 2005
 
 
". . . if you have GUI Unicode (multilingual) requirements then yes, you will need to get into Tnt controls or look into VCL.Net (Delphi 2005)."

anon and anon -- Vast majority of Delphi apps are db front ends that are based on a GUI, so this is main issue.  Assuming the TNT Unicode library works well then there are still issues: 

(1) Are there string functions used in code that don't support unicode and don't have unicode replacements in TNT or other unicode library?

(2) Do the dataset components used to access the database support unicode (for things like client-side filtering, searching, processing of string fields)?  I don't know, but I doubt whether the standard ADO controls shipped with Delphi do.  I expect there are 3rd party db components for accessing SQL Server from Delphi that would, but I don't know.  At very least, it's another issue to check into.

(3)  Does the current reporting solution support unicode?   

(4)  Since OP's project uses Woll2Woll grid, which doesn't support unicode and for which TNT controls provide no help, what solution would work for that?  Leaves open the .NET conversion route, since I think Infopower does have VCL.NET version, but as far as staying with Win32 this places a major crimp in things.

Maybe all this would sort itself out fairly smoothly if you wanted to convert a big existing Win32 app to unicode.  Somehow I doubt that, though.  Conversion to .NET seems like best route, if the conversion to unicode is going to happen at all.
Herbert Sitz Send private email
Monday, September 12, 2005
 
 
>> Conversion to .NET seems like best route, if the conversion to unicode is going to happen at all.

I agree. Unicode and "international support" inclusion in an existing Win32 application will be a grind. Delphi .Net will give you Unicode on a platter, more or less. .Net appears to be the future of Microsoft-platform enterprise software. So direct conversion to .Net seems to be the best alternative in order to realize both goals.
Bored Bystander Send private email
Monday, September 12, 2005
 
 
I've actually had to do this to a pretty big app, albeit all non-visual .. it was tedious and time consuming as you've predicted.  It isn't undoable, but I think your idea of client funded development (or partial?  maybe 50/50?) is a good one.  A gentle suggestion ... have a test plan to go through every scrap of functionality ... all the regression testing just sucked.
brad Send private email
Tuesday, September 13, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz