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.
Related
Just for test how hard to convert my Delphi 7 program to Delphi XE 5 i wrote simple application on Delphi 7 - placed TStringGrid on Form, and added code on form create:
procedure TFMain.FormCreate(Sender: TObject);
begin
With StringGrid1 do
begin
Cells[0,0]:='čęжэ€';
end;
end;
(actually it wrote as Cells[0,0]:='ce??€', but i expected that). Compile, build, run, no Unicode, of cause. Then reopened project in Delphi XE 5, changed line again to Cells[0,0]:='čęжэ€', compile, build, run - and no Unicode (got something like čę|||) ! That was strange to me. New project build from zero on Delphi Xe 5 with the same code, same TStringGrid is working as expected. I know here is some simple trick, maybe some change in project settings, but i can't google it... Maybe someone can help ?
Best regards.
The default font used by Delphi 7 is MS Sans Serif. When you use this font under Unicode Delphi, the string grid control appears not to draw text correctly with that font. Many other controls will draw your text correctly in that font. But for some reason the string grid control cannot manage to do so.
When you upgrade an old project to XE5 you inherit that Delphi 7 default. When you create a new project in XE5 the default font is different, Tahoma I think, and the string grid painting correctly shows your Cyrillic in that font.
You can work around this problem by using a different font like Tahoma or Segoe UI. You surely don't want to be using MS Sans Serif anyway. A list view in report view style would be another good option. Not least because it is the native platform control.
I must admit that I do not really understand why the string grid control is not behaving better. It would be great if somebody else could shed some light on this.
As David mentions, the issue is the font used in your string grid. However, it is not strictly accurate to say that the default font in Delphi is MS Sans Serif. It used to be MS Sans Serif but was changed (in Delphi 2006) to Tahoma.
You can see how a particular version of Delphi chooses the default font by inspecting the source of the Graphics unit in the RTL source of that particular Delphi version (since the IDE is built using that code). Specifically the InitDefFontData procedure (and, in older versions of Delphi, the DefFontData record).
As of (at least) Delphi XE4 the default Tahoma font will be replaced by any setting for a font substitution for a value identified as MS Shell Dlg 2, as set in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes\
NB - from inspecting the code in XE4 it is possible that if this key does not exist or cannot be accessed, or if there is no substitution entry for MS Shell Dlg 2 font, then MS Sans Serif will still be used. It is hard to tell since this is the behaviour when "CLR" is defined, which should not be the case any more since Delphi no longer supports .NET and the IDE is presumably not compiled with CLR defined, but there is no way to be certain simply from inspecting the code what conditional defines might be applied when the IDE is compiled.
However, whichever font the IDE is using and however it is choosing that font, this affects only new forms created in the IDE.
For existing forms, as in this case, the issue is not with TStringGrid as such but rather the fact that you created the project in a version of Delphi which applied a default font which did/does not support Unicode.
The act of opening the project in the newer version of Delphi did not change the font used in your form(s), so the form saved in Delphi 7 using the MS Sans Serif font is still using that font when opened in Delphi XE5.
The TStringGrid control is then using the MS Sans Serif font because this is the font set on the form, and the default for controls on a form is to use their parent control font.
i.e. This specific instance of TStringGrid is using MS Sans Serif because the form on which it is placed is (still) using MS Sans Serif.
In such cases you should change the form font to Tahoma or a. n. other suitable, Unicode enabled font.
All controls on the form still set to use their parent control's font will then adopt this font also. When performing this on an actual application you may find some controls with ParentFont set FALSE which will need to be addressed individually and that even where font settings are being "inherited" your form designs may need further work to tidy things up due to changes in appearance resulting from the change of font.
Note that even this change to Tahoma has been overtaken by changes in Windows itself, and if you wish to apply some other default font (in new forms/projects) you may find useful information here.
we have a application written in vb6, we also have the multilingual support for this application, we provide all the user message along with the ID's in .LNG file but application is not supporting the Unicode language like Japanese, Chinese etc.,can anyone suggest how to proceed the minimum change in the code and make this work !!!
Thanks
Standard VB6 controls doesn't support UNICODE. It is possible to use MS Forms controls (FM20.DLL). INFO: Usage and Redistribution of FM20.DLL.
The problem is that old version i buggy and is updated by MS-Office. New version of office id 64-bit and doesn't contain 32-bit FM20.DLL. I think it it only 'simple' way of implementing UNICODE but still it is massive change to the application.
Howerer VB6 supports different languages at least European, but the texts have to be properly encoded (Code Page Identifiers). I suppose that usual Windows font such as MS-San Serif, Arial supports most of languages.
If the windows default language is set properly other language characters should work. See e.g. HOW TO:Change language settings in Windows XP or try Japanese windows direclty.
I got some forms in Delphi 7 which I open in my IDE. Certain accented characters are not displayed correctly in the form and when I change a form containing such a character , the accent is lost.
E.g. something encoded as #337 a in dfm becomes u in the saved dfm
Can you tell what may be wrong?
update:
Problem for fixed after I changed in Control Panel, Region and Language, Tab Formats.
I changed the format from English to the language that has accented character.
Delphi 7 does not support Unicode, only ASCII. That's why the "extra" characters are not displayed.
The controls are capable of showing unicode (because Windows does). But the dfm files are still ASCII, and you have no guarantees about characters above 127. (And the VCL does not support them either).
You can switch to 2010 or 2011 (XE) for Unicode support.
In a non-unicode delphi version (delphi 7 for instance), if your current codepage supports a character, then Delphi will store your accent character into the DFM. If you reload on a system that is set to a different codepage, you won't see that character.
In a unicode Delphi (2009 or later) you will be able to store any codepoint you want into the DFMs.
AFAIR, all dfm content is encoded as UTF-8, in the dfm files produced by Delphi 7.
So you could be able to use whatever character you need.
But you need to set the proper Font CharSet property value for the component.
I have a Borland C++ Builder VCL app (so I am not working with Unicode yet),
I want to provide a simple translation of controls' caption text to Russian at runtime.
I can easily use EnumChildWindows to get the English caption, then lookup the translation and replace the caption text using SetWindowText. This does work well for my western European translations where I don't have to worry about the font.
But I am not sure how the Russian version of Windows and then VCL handles 8 bit cyrillic character sets.
Currently all the VCL controls have the font settings:
Charset=DEFAULT_CHARSET
name=MS Sans Serif
Am I correct in assuming that when my program is run under a Russian version of Windows the
character set will be cyrillic with the DEFAULT_CHARSET setting so I won't need to
change the font settings in all my controls?
If I do have to change the font (at run time), should the Windows API function SendMessage(hwnd,WM_SETFONT,(WPARAM)hFont,TRUE) work with VCL controls ?
I have tried using the CreateFont() and SendMessage(..WM_SETFONT..) with RUSSIAN_CHARSET and a cyrillic font face. This doesn't appear to have any effect,
it keeps the font that was set for the control in the form at design time
(even ANSI_CHARSET and a standard Windows-installed font face doesn't affect the controls' font) so I looking for confirmation that I won't have to change the font of the controls, or else tell me some VCL method for setting all the controls' font settings at runtime .
There is no need to reinvent the bicycle. Why don't you use Integration Translation Environment Tools which are provided with Borland C++Builder? There is a wizard that will help you with translations and will make a special resource file which will contain translation of all text strings in your application. Then program, will check system language and availible language resource files at startup, and will automatically use appropriate language. Check C++Builder help system with index - "Integrated Translation Environment (ITE)" for more detailed process description.
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.