View Issue Details

IDProjectCategoryView StatusLast Update
0017545LazarusIDEpublic2011-12-01 11:25
ReporterKurt FitznerAssigned ToVincent Snijders 
Status closedResolutionfixed 
Product Version0.9.28.3 (SVN)Product Build 
Target VersionFixed in Version0.9.29 (SVN) 
Summary0017545: Resources always end up with compiler computer's local language rather than project language
DescriptionProject resources (icon, mainicon, version info, etc) always end up being compiled into the project under the language the computer compiling the project is set to, rather than the language the project is set to. This makes it difficult for resources to be located by the software. This is also the case for any resources that are compiled from .rc scripts where the .rc script does not explicitly set the language.

The resources should either be added as language 0,0 (language neutral), or as the language set in the project options for that project.
TagsNo tags attached.
Fixed in Revision
Attached Files


Vincent Snijders

2010-10-29 10:58

manager   ~0042296

Is this a compiler/fpcres issue or an issue with how the IDE creates the resource files?

Paul Ishenin

2010-10-29 11:01

manager   ~0042297

Do you use some test program to show the error?

Kurt Fitzner

2010-10-30 23:57

reporter   ~0042462

I don't think the problem is with fpcres. If I am not mistaken, fpcres is not used to compile .rc files. My understanding is that it is windres that is used by Lazarus to compile .rc files into .res files.

By default, if there is no language specified in the .rc file itself or on the command line, windres will compile a .rc file to a .res using the language code of the language the local computer it is being run on is set to. My computer is set to 'English, Canada' and the corresponding code for this region is (0x0409). If resource scripts don't specify a language, on my machine windres compiles them as if the language code specified is 0x0409. You can specify in resource scripts what the language code is, but the resource scripts that Lazarus generates doesn't do that. You can specify what the default language should be on the command-line (--language=<langcode>), in which case, any language codes specified in the .rc scripts will still take priority, but any resource scripts without a language specified will take that default.

So, you whether this is an issue with the IDE or an issue with the way FPC calls windres depends on your thinking. It could be called a problem with Lazarus for not creating .rc scripts that specify the language code for resources. It could be called a problem with FPC for not specifying a default language. It could be called a problem with windres for defaulting to the local computer, rather than to zero (zero means the resource is language-independent).

If you are asking my opinion, I think there actually two issues here. The basic problem goes right back to windres. The language of a resource should default to 'language independent' if it isn't specified. I don't think the resource compiler should be deciding that setting a language is appropriate for every resource. It is not up to the resource compiler make that assumption. The native Windows resource compilter (rc.exe) shipped by Microsoft doesn't do this. It defaults every resource to 'language-independent' unless the script explicitly sets it. Failing patching windres or getting GNU to change its behaviour, I would then suggest the next level this issue should be fixed is at the FPC level. It should call windres with '--language=0' switch to make resources language-independent unless the resource script specifies one. If this can't be done, then the last resort is for the IDE when it auto-generates projectname.rc to specify a language for each resource.

The second problem, though, is that there are resources that Lazarus automatically puts into projects where it IS appropriate to specify a language. It may be the case that not every Lazarus resource should be 'language-independent' by default. For example, the 'Version Info' resource has text in it, and it may be appropriate to set the language for it. In this case, though, I would suggest that Lazarus should write the projectname.rc resource script so that the language for this resource is explicitly set to whatever the project language is.

2010-10-31 00:11 (13,542 bytes)

Kurt Fitzner

2010-10-31 00:16

reporter   ~0042464

Regarding a test program, any project created demonstrates the issue. I have attached a small test case, though. The project options has the language set to 'American English', but when I compile the program, every resource ends up being set to the language code for Canadian English. When you compile the program and look at it in a resource viewer, you will see that all the resources are set to whatever your local computer's language is. Changing the project language has no effect.

Paul Ishenin

2010-11-01 02:36

manager   ~0042523

Please try Lazarus 0.9.29. We don't use windres and .rc files anymore. Maybe the problem is already gone.

Vincent Snijders

2010-12-01 09:18

manager   ~0043831

Fixed by using FPC resources.

See: Project -> Project Options -> Miscellaneous -> Resource type of project.

Issue History

Date Modified Username Field Change
2010-10-04 21:13 Kurt Fitzner New Issue
2010-10-04 21:13 Kurt Fitzner Widgetset => Win32/Win64
2010-10-29 10:57 Vincent Snijders LazTarget => -
2010-10-29 10:57 Vincent Snijders Status new => acknowledged
2010-10-29 10:58 Vincent Snijders Note Added: 0042296
2010-10-29 11:01 Paul Ishenin Note Added: 0042297
2010-10-29 11:38 Vincent Snijders Status acknowledged => feedback
2010-10-30 23:57 Kurt Fitzner Note Added: 0042462
2010-10-31 00:11 Kurt Fitzner File Added:
2010-10-31 00:16 Kurt Fitzner Note Added: 0042464
2010-11-01 02:36 Paul Ishenin Note Added: 0042523
2010-12-01 09:18 Vincent Snijders Status feedback => resolved
2010-12-01 09:18 Vincent Snijders Fixed in Version => 0.9.29 (SVN)
2010-12-01 09:18 Vincent Snijders Resolution open => fixed
2010-12-01 09:18 Vincent Snijders Assigned To => Vincent Snijders
2010-12-01 09:18 Vincent Snijders Note Added: 0043831
2011-12-01 11:25 Marc Weustink Status resolved => closed