[fpc-pascal] resourcestring and const arrays
Craig Peterson
craig at scootersoftware.com
Sat Jun 25 19:01:43 CEST 2011
On 6/25/2011 7:55 AM, Marco van de Voort wrote:
> Well, then explain why Delphi + XE has exactly the same problem.
Delphi + gettext does, yes, but Delphi + resourcestring + resource dll
does not. Resourcestring is a language feature; gettext is a
third-party library. I'd expect them to have different semantics. As a
language feature, the compiler/rtl should provide a way to translate
resourcestrings and have it work correctly. The fact that FPC uses
gettext and Delphi uses stringtables on the backend are irrelevant
implementation details.
> What you are trying to do is implementation defined.
Obviously, but it shouldn't be. "resourcestring" means "I want to
translate this string, but the code should work like a regular string".
IMO, FPC's behavior breaks that contract.
> More or less. When localizing, the default windows resources model simply
> loads a resource dll (containing the localized data including copies of all
> forms, so an user can adjust e.g. the width of a text field) over the
> addresses where in the main .exe the original resources are.
That's incorrect. Resource DLLs are loaded using LoadLibrary, just like
regular ones, and then you pass that handle to FindResource/LoadResource
to load the localized version. If you pass a nil handle in it will
still return the original untranslated version. Delphi's DFM loading
and resourcestring implementations hide those details, but they are
explicit actions on the RTL's part.
> Hence their (gettext) behaviour in Delphi is exactly the same as in FPC.
Don't confuse using gettext explicitly through _() and implicitly
through resourcestring. In Delphi, accessing a resourcestring
translates into a call to LoadResString(), which uses
FindResourceHInstance to load from the translated DLL. On FPC, it just
reads directly from a variable you can update with SetResourceStrings.
The difference is that if you have a const reference to one Delphi does
a separate pass that fixes those references as well with a explicit
LoadResString calls during program initialization. It could just as
easily use gettext() to retrieve the translated strings, and that's what
dxgettext's AddDomainForResourceString does. If it
AddDomainForResourceString doesn't update the const references properly,
it's just because it isn't calling the routine that does those const
fixups (System._InitResStrings).
Basically, to get the correct resourcestring behavior, FPC would have to
maintain a similar table of resourcestring const references, and when
you call SetResourceStrings it would have to update those references
too. It would require changes to RTL and the compiler (to build the
table), but the gettext functions wouldn't be affected at all.
This is getting pretty technical though. Would I have better luck on
fpc-devel?
--
Craig Peterson
Scooter Software
More information about the fpc-pascal
mailing list