Re: [fpc-pascal] resourcestring and const arrays
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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] resourcestring and const arrays
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
Re: [fpc-pascal] resourcestring and const arrays
On 6/24/2011 4:52 PM, Krzysztof wrote: I had similar problem, I think that this is because consts are "filled" when compiling and there is no way to change them at runtime. Try this trick with pointers: Thanks Krzysztof. That looks like the least invasive approach, so if I can't get them working correctly that's what I'll do. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] resourcestring and const arrays
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. I could use SetResourceStrings directly (objpas.pp) and it will have the same issue. 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? 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. Assuming Krzysztof is correct that the compiler flattens the references, I'm guessing replacing the FPC_RESOURCESTRINGTABLES section won't help either. If it would, I'd be happy to look into that approach too. If fixing this is correctly is a reasonable possibility, I'm happy to look into it myself, but I would like to hear how attainable it's likely to be first, since I've never worked on a compiler before. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] resourcestring and const arrays
Hi, I had similar problem, I think that this is because consts are "filled" when compiling and there is no way to change them at runtime. Try this trick with pointers: resourcestring SSunday = "Sunday"; const SWeek: array[0..0] of PString = (@SSunday); begin WriteLn(SWeek[0]^); end; Regards 2011/6/24 Marco van de Voort > In our previous episode, Craig Peterson said: > > In Delphi I can use resource strings with const arrays and everything > > works correctly. For example, if I have a resource DLL with translated > > strings and this will work: > > > > resourcestring > >SSunday = "Sunday"; > > > > const > >SWeek: array[0..0] of string = (SSunday); > > > > begin > >WriteLn(SWeek[0]); > > end; > > > > I've tried doing the same with FPC's GetText unit and > > SetResourceStrings. SSunday gets translated correctly, but SWeek > doesn't. > > > > Is that something that should work if I'm early enough in the > > initialization order, an unimplemented feature, or something that's > > unlikely to changed? > > No, this is a problem of gettext. If you use dxgettext on Delphi instead of > Windows built in resourcesystem there is the same problem. > > For this to work you really need resource types that work based on > replacing > memory areas, or use _() > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] resourcestring and const arrays
In our previous episode, Craig Peterson said: > In Delphi I can use resource strings with const arrays and everything > works correctly. For example, if I have a resource DLL with translated > strings and this will work: > > resourcestring >SSunday = "Sunday"; > > const >SWeek: array[0..0] of string = (SSunday); > > begin >WriteLn(SWeek[0]); > end; > > I've tried doing the same with FPC's GetText unit and > SetResourceStrings. SSunday gets translated correctly, but SWeek doesn't. > > Is that something that should work if I'm early enough in the > initialization order, an unimplemented feature, or something that's > unlikely to changed? No, this is a problem of gettext. If you use dxgettext on Delphi instead of Windows built in resourcesystem there is the same problem. For this to work you really need resource types that work based on replacing memory areas, or use _() ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] resourcestring and const arrays
In Delphi I can use resource strings with const arrays and everything works correctly. For example, if I have a resource DLL with translated strings and this will work: resourcestring SSunday = "Sunday"; const SWeek: array[0..0] of string = (SSunday); begin WriteLn(SWeek[0]); end; I've tried doing the same with FPC's GetText unit and SetResourceStrings. SSunday gets translated correctly, but SWeek doesn't. Is that something that should work if I'm early enough in the initialization order, an unimplemented feature, or something that's unlikely to changed? Thanks, Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
