|
|
2016-01-24 09_08_32-Lazarus.png (73,465 bytes) |
|
|
The revision is 51246 (1.6RC2). |
|
|
I cannot reproduce this with 1.6RC3 (r51531) nor trunk (r51439). Tested on Win7, with username being "บลูเบอ". Note that these caracters fall outside of my current codepage (Western European). Lazarus correctly creates the C:\Users\บลูเบอ\AppData\lazarus folder and writes it's config files there. Q1: are cyrillic characters inside your current windows codepage? Q2: did you use the DisableUtf8RTL feature? |
|
|
Answer 1: I think, that the characters inside codepage 1251, because it's Windows default codepage (Russian). The folders was created by the system ('c:\users\Юрий') or in the Explorer (for testing secondary installation). Answer 2: If I correctly understand, DisableUtf8RTL feature is used in a project options. But this error prevents Lazarus installation. Therefore, DisableUtf8RTL feature may not be affected by this bug. Correct me please if I am wrong. If needed, I can provide remote access in a few days to test this error. I would be happy to help any way I can. |
|
|
DisableUtf8RTL will probably make it impossible for Lazarus to create it's default config folder _if_ the usernamehas unicode characters outside the current codepage. Note also that when username has unicodecharacters outside the current codepage, the compiler will not be able to compile the project, As a (temporary) workaround you can set --pcp=somepathwithonlyasciicharacters. |
|
|
Thank You for this workaround. Lazarus 1.6 (r51630) is released! But the bug is stil here :-( Tested on Windows 7 x86, secondary installation. Lazarus path = 'c:\Лаз\', config path = 'c:\Лаз\Сет\'. |
|
|
2016-02-18 20_49_03.png (26,119 bytes) |
|
|
2016-02-18 20_49_46.png (8,397 bytes) |
|
|
I can give you remote access to the (virtual) machine for all those who would like to test this bug. Does this help anyone? |
|
|
@Yuri: not me. |
|
|
I've tested it today too. I can't start a Lazarus installed in a directory C:\Lazö. Windows 7 64bit, Lazarus 1.6.0 32bit. Dubug.log added. |
|
|
|
|
|
It's not about the Lazarus directory, but about the config directory. The compiler an tools (make etc.) may very well not like C:\Lazö, but Lazarus iteslef should have no diffuculty writing it's confi files to e.g. C:\Users\Lazöäïü\AppData\local\lazarus. |
|
|
Bart, it seems to me that conversion from special dir to unicode string used for config file missing. You may check this first. BTW, why conversion need to be forced anyway with SysToUTF8 or UTF8Encode? Global problem here made different main codepage by different OS. However, I do not see the reason to force programmer to do that. When use load or save method for any library, it should be assumed that is in UTF8 or widestring and make these methods overloaded dependent of used OS. For these OS not use any unicode, it is assumed to use ANSI string only. And where such path info is stored? File have BOM sequence? If not, what content using BOM or not should be treated on different OS? AnsiString, String, UnicodeString, WideString... + different OS unicode support - all makes quite a confusion by default. I do not want to argue here at all - it is simply much more logical instead to force programmer to do such conversions and obviously similar errors are unavoidable. |
|
|
> It's not about the Lazarus directory, but about the config directory. OK, i missunderstood the topic. A config directory á la C:\Lazarus\ConfigÖ works fine here. |
|
|
@sasa: see my note 0089817. Lazarus can handle the C:\Users\บลูเบอ\AppData\Local\lazarus path were it stores it's config. Even though this path contains unicode characters that are outside my current codepage. So, it's a mystery to me why this does not work with Cyrillic or Danish characters. |
|
|
I have read it already and my answer is the same as Yuri's. Old Windows (as 95) does not supported unicode and based purely on default codepage, thus programs are also made for specific codepage or English codepage only. That made quite a confusion. From Windows2000 (or so), they started with full unicode support, however, localization stays as codepage default settings. That is: if OS default codepage is set to 1251 (Cyrillic) i.e. Russian localization, all files wrote by Russian cyrillic internally are recognized as such (one byte character). However, Lazarus seems to do or not some improper conversion or/and triggering use of ANSI or widestring API or similar calls... And that may be reason why is not possible to install Lazarus in path uses specific codepage. Just speculations... When test such condition, suggestion is to use full unicode text, mixed different codepage characters than OS is localized. For instance: Юрий_ŠĐČĆ Upper have CP1251 and CP1250 characters (you may add Greece chars, etc), ensure that conversion should be handled as unicode, not by specific codepage... The cause of the problem then should be found fast and without doubts. |
|
|
> all files wrote by Russian cyrillic internally are recognized as such (one byte character) That's about the contents of the file. The issue is about the filename, which AFAIK Windows internally only uses widestrings. |
|
|
Lazarus retrieves the default location where it stores its configfiles using GetAppConfigDirUtf8 function (in LazFileUtils unit): PrimaryConfigPath:= ExtractFilePath(ChompPathDelim(GetAppConfigDirUTF8(False))) + 'lazarus'; Can you inspect what the content is of GetAppConfigDirUtf8(False) on your system? It should return a filename encoded in UTF8, so please inspect if it is properly encoded. The wrting of the xml file in the end is done by Laz2_XMLWrite.WriteXMLFile which expects an UTF8 encoded filename and uses a TFileStreamUTF8 which then translates the UTF8 to WideString. |
|
|
When I launch program from Lazarus LazFileUtils.GetAppConfigDirUtf8(False) return this text: "D:\mb\_Test_2\". This is the project path. When I launch compiled program directly: "C:\Users\Юрий\AppData\Local\project1\". This is correct path. |
|
|
> "C:\Users\Юрий\AppData\Local\project1\". And exactly that C:\Users\Юрий\AppData\Local\ is used by the IDE to to determine where it stores it's config files. |
|
|
I think that the error is not in this function. The problem arises when I use the secondary installation, if I specify a path that contains Cyrillic letters. |
|
|
> if I specify a path that contains Cyrillic letters. How did you specify the path? On commandline or in the .lnk file (shortcut file) |
|
|
> How did you specify the path? In Lazarus secondary installation dialog box (selecting path to config files). |
|
|
I found the problem. Partially. After secondary installation in the Lazarus folder created file "lazarus.cfg". This file contains the path to the settings file. The contents of my file: --primary-config-path=C:\Лаз\Сет The file is stored in the system default encoding. CP-1251 in my case. In this case Lazarus is started with an error. If the same content stored in the UTF8 encoding, then everything works fine. In these folders are stored configuration files. Specify the path through addind "--primary-config-path" to the .lnk is works fine. Through the commanline is also works. I think that a similar problem arises in the normal installation when using the default path. Encoding perceived wrong. |
|
|
The lazarus.cfg is created by the installer? (I only build from sources and I have no lazarus.cfg anywhere) |
|
|
Thoughts (assuming we can't get the installer to write UTF8); Do we (Lazarus) ever write to lazarus.cfg file? If not (only the installer writes), then on Windows we can simply change the encoding from WinCP to UTF8 upon reading the file (in IDECmdLine unit)? If we also do write ourselves, then upon applying the read information we could check if the directory exists and if not assume the string is actually Win codepage, convert it to UTF8 and check again? Or: read lazarus cfg, if the text contains any char > 127 and it is not valid UTF8, convert all the text to UTF8, save it as UTF8 and be done with it? |
|
|
idecmdline.diff (769 bytes) |
|
|
Can you please test with attached patch (idecmdline.diff)? |
|
|
Yuri, ping ... Also others please test the patch. |
|
|
Please test and close if OK. |
- Anonymous
