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.
Related
I develop a delphi7 webbroker multilanguage application for apache2,2. The application is using Oracle xe11 for data storage, and Devart's ODAC components to communicate with the Database. I set up the Orasession component as to use Unicode. The data inside the database was stored properly in Unicode capable data type columns. With another desktop application , also written in Delphi 7 we are able to store, retrieve and display correctly the same data of the database (I’m using Unicode capable components). My problem occurs when I want to display these data with the webbroker appl in html format. I’m using the default components provided by delphi 7 (TWebResponse). All text which are in Latin characters displaying correctly but all the others which are in different languages (not latin) not. Can you suggest me what have I do to solve the problem?
(How) do you encode the unicode output of your components to the non-unicode capable (Ansi)String of TWebResponse.Content?
I guess the system codepage does not contain Ü (probably the same as the German Umlaut Ü -> U+00DC) and you are using an implicit conversion to (Ansi)String that takes the best mapping it can.
At least in Delphi 2006 you can / have to use
function Utf8Encode(const WS: WideString): UTF8String;
in system.pas (utf8string is a string - defined in same unit). As far as I know that function was there also in in Delphi 7.
You can't but you can work around it.
Label1.Font.Charset := TURKISH_CHARSET;
Mess with the Charset property to get what you want.
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.
A client is reporting an issue whereby she is copying from an e-mail into a screen in a program we have created with Delphi 5. The component on this screen to which she is copying is a TMemo component.
When a line of text contains an ellipsis (...) character or closing quotation marks character ("), the text is replaced with a vertical bar. If the text has two periods in a row, the periods appear correctly. When using the single quotation mark ('), the text appears correctly.
In testing this, I was able to replicate this issue from within an Outlook client and Word document. The error does not occur when copying text from within Notepad. The error also does not occur if I create the text from within the TMemo component, copy it into Outlook or Word, then copy it back into the component.
You are using Delphi 5 which is an ANSI version of Delphi. The characters that you are trying to copy do not exist in the ANSI character set that your client is using. There is no solution to this problem so long as you persist with ANSI controls. Your options:
Switch to a modern version of Delphi that supports Unicode, or
Use TNT Unicode controls with your legacy Delphi.
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.
I have an application which is fully unicode compatible in Delphi 2006. I had replaced all AnsiStrings with WideStrings, replaced all VCL controls with TNT controls, and changed all string functions from AnsiStrings to WideStrings. It looks like all that work was for nothing, because I'm going to have to reverse it all. Is there anyway to Trick Delphi 2009 into thinking Widestrings are in fact UnicodeStrings?
No, there really isn't. But you won't regret the work to truly Unicode enable your application.
The TNT controls can easily be replaced with the regular VCL controls. You can do that pretty simply using the wizard from GExperts (http://www.gexperts.org) that replaces one control type with another automatically.
Then, you can change all your WideString declarations to regular strings. String is now an alias for UnicodeString, and so all your strings can hold Unicode data just fine.
BTW, the author of the TNT controls, Troy Wolbrink, now vastly prefers Delphi 2009 over his own controls.
Main advantage of TNT Controls is only that It can work as Ansi program in Windows 9x. It is not full unicode. If you want full unicode support everywhere (such as Stringlist.LoadFromFile, Form.OnKeyPress) it's good to move to Delphi 2009.
I have done the same thing in an application that used different XML files as input. In my case, I was working with UTF-8 (so we could use regular strings) throughout the program and only converted to WideString for display purposes (TNT controls).
I removed the conversions back and forth between WideString and UTF-8 and replaced the TNT controls with regular VCL controls by hand since there were only a handful of forms.
The conversion took about an hour with testing. The code is simpler and the program is noticeably faster.