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.
Related
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 have an English version of the Windows XP operating system installed on my computer. If I try to use the Russian input language, for example, to give a form a caption that's written in Russian, the only thing I see is those unintelligible symbols that you often see when there is a problem with proper character encoding. Is there a way to make Delphi recognize Russian characters?
Any suggestions will be highly appreciated.
You can change default code-page used for programs that do not provide locale info (Control Panel > Regional setting > Advanced) to your locale (Russian).
As for SQL that is a separate question probably solved by SQL DB settings.
P.S. I would suggest you to move to Unicode version of Delphi (XE) and SQL too.
We're programming in Delphi 2006, using Multilizer 5.1 to translate the program. Now we've to added Polish as a new language in Multilizer. But when we open our executable, Multlizer says "Polish is not supported by the codepage".
If we adjust our regional settings to Polish, whenever we open the executable, the regional settings flip back to the original setting, which is Dutch. Maybe we should set the CodePage setting in our Project Options, but the dropdown list does not give us any options.
Any ideas?
So it turns out we only had to set the Language for non-Unicode programs in the Regional and Language Options in Control Panel. The bad news is that the French version is now having the same problem.
If you want your application to support all possible language regardless of the Regional and Language Options on the user's computer, you'll need to migrate your application to Delphi 2009 or later. Starting with Delphi 2009, Delphi produces Unicode applications. It'll likely take some effort to fix any code that assumes that SizeOf(Char) = 1. But that one-time job should be much less effort than constantly having to deal with code page issues in your Delphi 2006 application.
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.