In non-unicode Delphi (I've tried with D7 and D2006):
Put a TRichEdit on the form and run the application
Switch to some "exotic" keyboard layout (Russian, Greek, whatever)
Type something
On XP, everything is good and I can see normal Russian letters. However, on Win7 characters are wrong (accented letters from other languages). If I copy Russian text from MS Word and paste it to RichEdit, it looks OK.
I suspect it is something related to RichEdit control version, but it there any way to overcome it? If possible, I would like to avoid switching to TTntRichEdit (which appears to work correctly), as I would need to change lots of existing code.
Try to use converions like AnsiToUtf8 or AnsiToUnicode, when user presses a key.
Related
Since some days, my Delphi 2007 IDE has stopped formatting hint's text.
When the cursor moves over a class or a function, it displays hints as plain HTML text.
Syntax highlight is active and as far as I remember, I didn't change any option in the last months.
The only thing I can suppose is that, maybe, Windows 10 updates could have caused this problem but I'm not sure about that.
Am developing a Delphi firemonkey desktop application with XE5.
I use Unicode characters to localize the application (Asian language call Sinhala).
Everything is perfect with windows 7 (We haven't tested it with Vista). But when we test it with windows XP, it display every character as a box (except in title bar).
What is the problem? Is delphi firemonkey support unicode in XP?
Is there any way to get it display correctly on XP?
(This happens only with firemonkey, everything is OK with VCL. Since am going to make it support for MAC, I have to use firemonkey.)
AFAIK FireMonkey does not implement the so-called Font fall-back mechanism. It does not use the Uniscribe API.
I suspect the font you are using (e.g. Tahoma) does not contain the needed characters in XP - whereas the TTF file included with Seven/Vista does contain them. So FireMonkey is not able to display the text as expected in XP.
Change the font to one having all needed glyphs. You may have "Arial Unicode MS" available, even on XP, if you have MSOffice installed.
By default, the VCL renderer uses the ExtTextOut GDI API which does implement font fall-back, so it automagically searches the installed fonts for the missing glyphs.
To properly use/display Unicode the OS has to support unicode strings and you have to have fonts installed that can display the Unicode characters. Since their are 65000+ characters not all font manufacturers include every Unicode character.
I think the FireMonkey app uses a font that does not contain Sinhala characters. Play with the font used by the app.
If you need a Sinhala font, the wonderful Alan Wood’s Unicode Resources has a section Large, multi-script Unicode fonts for Windows computers. The South Asian font page names several fonts you can try.
Alternatively, Googing "sinhala unicode font" will also give you plenty of suggestions.
I have checked all these suggestions - but there is no useful turnout of my problem. I have found out the following facts.
Changing the font to Arial MS Unicode or replacing Tahoma with a TTF file from Windows 7 doesn’t work.
Changing the font to “Iskole Pota”, a font which support Sinhala Unicode symbols , solved the problem for TEdit component.
All the components which are descendents of TTextControl don’t work with “Iskole Potha” solution.
I have further noticed that changing the font to something like “Wingdings” for TTextControl descendants don’t show appropriate symbols either. They still show English.
I am currently converting a legacy system to a new platform and need to extract strings from the old systems resource files.
The old system was written in Delphi and the strings are kept in files called .dfm. I have no trouble locating the strings and for English and other European languages there is no problem. The trouble comes when I try to extract strings in Japanese. I have used Notepad++ and it seems to me that the program don´t recognice the correct encoding. I get Japanese symbols but they don´t seem to match what is in the GUI. Notepad++ shows signs in something called GB2312(Simplified Chinese). But it looks weird.
My question is, does anyone have any tips on programs/text editors that are good at operations like this?
Also I'm grateful for any tips that might help me along the way.
Assuming that your issue is simply that Notepad++ is incorrectly guessing the encoding you can solve the problem by manually setting the encoding in Notepad++, like this:
Notepad++ itself already handles encoding issues. To make it to desired encoding, like Unicode;
first, copy all the contents of the file,
choose Unicode without BOM in the menu,
last, replace all contents with copied contents
save the file
Your contents will then be in your desired encoding.
Strings are kept not [just] in DFMs in Delphi. Only forms and associated text are. So you would to review all the code as well.
As for DFMs - before Delphi 2009 DFMs didn't use Unicode so you must know what charset was used. That was one of big problems with localization and internationalization of Delphi applications.
Could anyone advise how to programmatically change the default Windows XP code page (I'm doing this from Delphi)? (This would be the equivalent of going into Control Panel -> Regional Settings -> Language for non-Unicode applications).
In this case, I want to switch to Chinese (PRC) and so am writing to the following registry strings:
HKLM\SYSTEM\CurrentControlSet\Control\Nls\CodePage\
ACP=936
MACCP=10008
OEMCP=936
(Which is exactly what changing the non-Unicode codepage drop down in Control Panel does). There must be another setting which I need to change - and I'd prefer to use a Win API call (if available) rather than writing to the registry myself.
I've also tried setting
HKLM\SYSTEM\CurrentControlSet\Control\Nls\Language\
Default=0804 (Chinese PRC) to no avail.
I don't want to change the 'locale' per se as this will also change time / date settings, separators, etc. etc.
This is because I'm using an ANSI application that needs to render Chinese characters, and I'm writing a tool to automatically switch the system show the characters (while leaving other aspects of the UI intact).
Thanks!
Duncan
The only time this would be appropriate is if you're writing a kiosk type application where nothing else will run on the system. That change will affect every other application on the system.
If you just need to render the characters and can get them into a WideString you can render them in older versions of Delphi by calling the W versions of the Windows APIs directly, rather than going through the TCanvas methods. That is, call DrawTextW or ExtTextOutW instead of TCanvas.TextOut and it will draw the Unicode characters without converting them to the system's ANSI codepage.
A more complete option is the TMS Unicode Component Pack. It supports making Unicode-enabled applications in Delphi 6-2007, and handles calling all of the W functions for you. It works well, and you can just use TCanvas or the Caption/Text properties like normal.; the only difference is the properties are all WideStrings instead. That was originally the TNT Unicode Controls pack, and there's an older, unsupported version of that available here.
Finally, you can use Microsoft's AppLocale utility to change the ANSI codepage for just your application. There are details on calling it from a batch script here, a patch to run it without the nag screen here, and a command line clone named SBAppLocale. It works, but it's a hack, and the other options are better long-term.
our delphi win32 app uses special characters like micro and copyright. we mostly use the arial. before delphi 2009, we had to provide a way to prevent the micro character from displaying since for some (many/most?) parts of the world, it was not displayed correctly. we'd replace micro with u, copyright with (C)...
now that we're in delphi 2009, can we leave out this option and display the micro & copyright symbols without needing to do this translation.
it would seem to me that this should work everywhere now without this lame replacement scheme now that our app is in unicode.
thank you!
Yes, as long as you're using Unicode strings and not ANSI strings, you can put in whatever extended characters you'd like, and they'll show up properly as long as the font you're displaying in supports them.
I'd test it in a few differnt languages first though. Unicode is not always as Universal as we sometimes believe.