views:

427

answers:

3

I've got a number of Delphi forms where we use a couple of special characters - the 'degree' symbol, and the 'ohms' symbol. These characters are used in label captions saved in the DFM file and are not generated or modified at runtime. Back along when we first designed these forms the degree symbol was easy because it is in the Ansi character set (code 176) but the ohms symbol needed the greek charset to be used with code 217. Fortunately (we found) all other characters that we need (letters and numbers) work fine with the greek charset.

Now we would like these forms to look the same in D2009. The degree symbol appears fine but the ohms symbol shows 'Ù' because the dfm text is "Caption = 'Typed in Ohms - 1234 '#217". I find that I can edit the form to put in the correct unicode ohms symbol (8486) but of course this is lost to a '?' when going back to D7. Ideally I'd like to tell D2009 to continue to use the greek charset with the form so that #217 in the dfm maps to the ohms symbol. Is this possible? It seems to ignore the Font.Charset setting which is 'GREEK_CHARSET'. I have discovered a dirty way of solving this which is to iterate through all the components and doing "StringReplace( S, 'Ù', OhmsChar, [rfReplaceAll] )", but this is horrible and surely there must be a better way?

Thanks, Brian

+2  A: 

The cleanest way I found to do this was to populate these "special" captions in code, where you can use IFDEFs if necessary.

Bruce McGee
+3  A: 

As Bruce already mentioned, you can use the code to give these values. I just give an example and some extra information.

resourcestring
{$IFDEF UNICODE}
  cOhm = unicodeohm;        // replace with correct values.
  cDegree = unicodedegree;
{$ELSE}
  cOhm = ansiohm;
  cDegree = ansidegree;

I advise to use resource strings and not const for translatable text, because most translation tools work on resources.

Gamecat
+1 for resource strings. They are the cleanest way to handle this and make later translation using existing tools a breeze.
skamradt
This is a good solution for code but how does this help with the DFM files? Thanks
Brian Frost
+4  A: 

Similar issue I had was solved by using dxgettext. Instead of problematic captions, I just used clean ascii (eg. "Typed in Ohms"), and then translated them in po files, embedded in exe as resources.

BTW, dxgettext is a nice way to add translations to app, with a very little overhead and standard formats (po/mo) with good 3p editors (poEdit). Works with D7 and D2009.

dmajkic
Interesting, thanks!
Brian Frost