I am setting Font.Charset to EASTEUROPE_CHARSET for all controls on my form. This works great for controls such as TLabel. But for controls that are simply a wrapper around a windows control, e.g. TButton, some characters are not displaying correctly.
Doing a Google search I have discovered that this is due to Font.Charset not matching the system codepage.
But I cannot find how to fix it. I am using Delphi 7, maybe this has been fixed in later Delphi's, I don't know.
Anyone help?
Thanks,
AJ
You need to change the system default language for non-unicode programs. It is in Control Panel, under regional languages and settings.
If you want to be multi-lingual in Delphi then you should just move up to the latest version. Working with code pages is a world of pain that disappears entirely when you embrace Unicode.
Delphi 7 does not have Unicode Support (Though it should have support for some European Languages) so this may be your issue. Delphi 2009 provides comprehensive Unicode Support to Delphi.
Related
I just upgraded from Delphi 2009 to Delphi XE8. Doing so has changed the appearance of the buttons on the toolbar of my program.
When compiled with Delphi 2009, it looked like this:
But now with Delphi XE8, it looks like this:
It seems to me that this is related to the Down property. If a Down property of a button is true, then its background will be blue. If I click on the button then that will change the Down property to false and the button will lose the blue background.
Does anyone know what might be causing the blue background and how I can eliminate it?
I am on Windows 8.1.
Followup: David's answer that this is the default display for Windows 8.1 is correct. Checking other programs, I see they do this as well.
I wasn't expecting this to be the default because my program compiled with Delphi 2009 didn't do this. But as David also explained, that's because Delphi 2009 did not have built in theme support, but Delphi XE8 does. (It may have been added in Delphi XE2, but don't quote me on that)
David's mentioned the manifest as a possible cause. It wasn't in this case, but he alerted me that I may have multiple manifests and should check for it.
So the final answer to my question is that I don't want to eliminate the blue background. It is the Windows 8.1 default way of displaying Down buttons, and I want to display the native theme by my program.
Your D2009 program is not themed, but your XE8 program is themed. By that I mean that the XE8 includes an application manifest that specifies version 6 of comctl32. Your D2009 program does not include a manifest, or does not include that part of the manifest which requests comctl32 version 6.
The visual appearance of the XE8 program is the native platform appearance, and on the face of it, it would be normal to follow the platform's lead. So the option that I would opt for is to leave the appearance as the platform standard. That is go with the XE8 version.
However, to answer your question, you can revert to the old appearance by removing the comctl32 v6 part of the manifest. This will affect other parts of your program too. If you only want to disable themes for the toolbar, that can be achieved with SetWindowTheme.
Win7 must give ok style for TSpinEdit, but I see outdated style:
So arrows are not themed, and buttons are old.
I use Delphi7. How to patch VCL to fix style?
OK is:
I don't know if Delphi 7 already had it but you can use TEdit in combination with TUpDown and then set the Association property of the TUpDown to your TEdit.
TSpinEdit is a custom VCL control. There is no Windows control with that functionality. Even in the latest version of Delphi it looks exactly the same as in Delphi 7. And it's really rather ugly isn't it?
The control, in modern Delphi, is implemented in a unit named Vcl.Samples.Spin. Looking at the documentation for the Vcl.Samples namespace we have:
Contains the units for several sample VCL components delivered with RAD Studio - a calendar, an outline, a gauge, and a spinbutton.
The unit will be named differently in Delphi 7, but the principle is the same. These are sample controls, supplied with source code.
So, what you may do is take a copy of the TSpinEdit code, and modify the painting. Change the button drawing to be how you wish it to be.
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.
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.
I have a rather large (freeware) project written with Delphi 2007 which is using both the TntUnicodeControls and the TntLXControls library and I'm planning to move to Delphi 2009.
Unfortunately I'm using those libraries everywhere in my project:
Replacement for VCL controls to provide Unicode capability
Win32 API wrappers (mostly for comparing strings)
The feature enhancements of TntLXForms, TntLXRegistry, ...
Third-party components which use TntControls. (VirtualTrees, SpTBXLib, updates for D2009 are available)
Do you have any experience and/or suggestions in porting such a project to Delphi 2009. Is it advisable to first switch to the (commercial) TMS Unicode controls?
Install GExperts; there is "Replace component" IDE addin that can help converting TTntXXX to TXXXX controls. Try for once, and if it's ok just check "Replace evrywhere in project".
SpTbx and VirtualTrees can only be recompiled - they both support D2009.
If you used WinAPI wrappers just to call Unicode API-s they should work in D2009 also.
That leaves you with TntLX controls (TntLXForms, TntLXRegistry, ...). Since they are unsupported, may be it is good time to change them anyway.
I can help with some of this, as I'm porting a C++Builder application that uses TNT from 2007 to 2009. The switch to Unicode in D2009 is overdue and welcome. However, it's unfortunate that the transition is probably easier for those who have NOT needed unicode in the past, and probably still don't. If, like me, you needed Unicode and used Troy Wolbrink's great TNT control to provide it, you have a rather more complex job...
The good news is that there's a new version of TNTControls from TMS Software which supports D2009. I haven't looked at this, but expect it is just a 'facade' layer over the native VCL components to ease portability. I'd consider that if your other libraries can be rebuilt to use it.
However, you may be better going back to native VCL controls, and the reason is string types. TNT control have always used WideString to pass Unicode strings back and forth, and you may well have WideString use scattered through your own code. This will work, but it's not ideal as WideString should really just be used for COM interop as it 'wraps' the COM BSTR type. Native unicode strings in D2009 are reference-counted and should be significantly faster.
If you do decide to replace TNT components with native VCL ones, you can use GExperts "Replace Components" command - or, maybe easier, do a search and replace in your .DFM and .PAS files (which you DO have in text form, don't you) to replace TTNT with T.
I recommend the following resources:
Marco Cantu's Delphi 2009 Handbook Chapter 3 (Porting to unicode)
http://www.marcocantu.com/dh2009/
Nick Hodges' articles (Delphi in a Unicode World)
http://blogs.codegear.com/nickhodges/2008/11/20/39149
I think either way it's going to be a lot of work. Probably more so than if you hadn't done all the work to make it unicode compatible before. I personally would forget about the tms Unicode controls, and go back to the vcl. It will save more pain in the future. (nothing against those controls, mind you.)
Also remember, that D2009's string, is not the same thing as D2007's Widestring which you have undoubtedly used in your app. So all instances of Widestring, which you so diligently changed from string (which was AnsiString), need to go back again to string(which is now unicodestring).