[fpc-devel] String handling in trunk (was utf8 in 2.6.0)

[Hans-Peter Diettrich]

Paul Ishenin schrieb:
> 05.01.13, 23:54, Michael Van Canneyt пишет:
> 
>> You are very much wrong.
>>
>> To start with, resource strings are not stored as Win32 resources.
> 
> I personally think that resources should be stored in their native 
> formats where is possible. This will allow to change them using software 
> designed for that environment. For example for windows there are many 
> resource editors which can replace icons, bitmap and string resources 
> too. It would be nice to have this ability also for binaries which FPC 
> do. On OS X resources are also stored different from what FPC do 
> currently - they are stored in application bundles as I know, so they 
> can be edited by external programs too.

Point taken :-)

But I'm not sure about nowadays use of native resources. Even on Windows 
most programs nowadays don't use Windows resources for their menus, 
dialog boxes etc. any more. I've used the Delphi ResourceWorkshop for 
some time, to tweak some third party programs and even Windows itself.

This will be almost impossible with current software. Try e.g. to set 
the Windows menu color to yellow, what I did for a long time, and you'll 
find out that the Explorer and many other Windows tools don't honor that 
setting. Or you'll find that these system settings have been removed at 
all, replaced perhaps by themes?

So I'm not sure about the use of native resources, nowadays. How should 
a multi-platform application handle a string or graphical (icon...) 
resource, so that it can be designed on one platform, and be shown on 
all other platforms without modifications?

With graphical resources I'd use a single internal (FPC) format, which 
is converted by the widgetset for use on the target platform. String 
resources may require more adjustments than only a translation, to match 
the different semantics of other languages - independently from the 
target platform.

That's why I'd suggest UTF-8 encoding for resource strings, what doesn't 
affect program logic because AnsiString still can be used. The *encoded* 
AnsiStrings require that the coder knows about the best encoding of 
every string, when he wants to reduce the number of implicit string 
conversions. Using AnsiString(CP_ACP) may be a reasonable decision for 
use in a program with *very* limited usage (one country, one language, 
one target platform...), but FPC should support programs with a broader 
audience as well.

DoDi