In our previous episode, Craig Peterson said: > On 6/24/2011 4:14 PM, Marco van de Voort wrote: > > No, this is a problem of gettext. > > It's a problem with FPC's resourcestring implementation, rather than > something specific to gettext.
Well, then explain why Delphi + XE has exactly the same problem. What you are trying to do is implementation defined. > > For this to work you really need resource types that work based on > > replacing memory areas, or use _() > > What do you mean by replacing memory areas? Runtime patching? 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. Gettext and other localization systems based are not based on this, but on a system that intercepts a call to the resource handling system (loadresstring iirc), and only work for resourcestrings (and not for the complete form data). The _() is a shorthand for gettext Hence their (gettext) behaviour in Delphi is exactly the same as in FPC. > Does > something exist that supports that? On Windows we're using resource > DLLs directly, without going through gettext, so I really don't want to > switch to _(). I don't mind low-level hacking though. ;) > It looks like Delphi writes a table of these kinds of resource string > uses and fixes them up during program initialization. If FreePascal had > a similar table it could do the same thing as part of SetResourceStrings. In 2.4.0+ resources should be mostly native. See the fpc-res package. On Windows it might work, if it uses windows resources and its policy as much as possible. But then you must also craft resourcedlls, and load them, and not use something else like gettext. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
