Michael Van Canneyt schrieb:
IMO resource strings are for display purposes, so that UTF-8/16
encoding is expected by an OS API. AFAIR Win32 string resources are
stored in UTF-16,
You are very much wrong.
Not really. I was talking about Win32 resources, not about what FPC
makes from resourcestring.
To start with, resource strings are not stored as Win32 resources.
Secondly, they are stored in the code as an ansistring.
The resource string of the above example is stored as:
.globl _$PROGRAM$_Ld2
_$PROGRAM$_Ld2:
.ascii "Something\000"
.balign 8
.short 0,1
.long 0
.quad -1,15
.globl _$PROGRAM$_Ld3
Thirdly: in my apps, no UTF-8/16 encoding is expected by the OS. If it
were, I would have used widestrings instead of ansistring to begin with,
and in that case I would not have made any remark...
I don't know which OS you're using, but the WinAPI uses UTF-16
throughout. I suppose that other OS also use some Unicode string
representation, for lossless representation of texts of all languages.
The dual W/A interface of Win32 is due to the stripped-down Win9x
versions, which require Unicode extensions for supporting more than
CP_ACP. But now we are in 2013, with Unicode being present everywhere.
So the conversion really would be 100% totally redundant.
It may look so to you...
Why then do you use resourcestring instead of ordinary string constants?
Another note and question, about multi-lingual resources. Windows
resource scripts (.RC) allow for multi-lingual stringtables. In my
recent research I learned that the resource compiler extracts the
requested language from the script, and stores only these strings in the
resource file (.RES) and application (.EXE, .DLL). That's why
resourcestring was added to Delphi.
How does FPC support the same? (.PO files?)
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
