View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0036193||Lazarus||LCL||public||2019-10-17 10:44||2020-07-15 20:50|
|Summary||0036193: win32 error with TOpenDialog.Execute|
|Description||Use crosscompile win32. |
Add TOpenDialog. Call TOpenDialog.Execute. After show OpenDialog raise exception - file C:\Users\РџРѕР»СЊР·РѕРІР°С‚РµР»СЊ\Desktop not exists. I think promblem OpenDialog use encoding Utf-8. Windows expect Win-1251.
|Tags||No tags attached.|
|Fixed in Revision|
Please attach a compileable sample program demonstarting the issue.
LCL is entirley UTF8 and the Win32/64 interface translates that UTF8 to UTF16 before calling the Windows API.
Demo project reproducing the problem in the attachment. I'm build and run x86 application on windows 64 bit. System language os - Russian.
In the attachment app32_os64.png show error. If I'm build and run x64 application on windows 64 bit no error, view app64_os64.png in the attachment.
errOpenDialog.zip (208,350 bytes)
So, if I understand it correctly then when you build this for Win64/x86-64 all is fine, but when you build for Win32/i386 and then run on Win64 you get an exception by just trying to excute a TOpenDialog?
Obviously I can't understand the error dialog in your attachment ;-)
Tested with FPC 3.3.1 built 2019-10-09 on i386-win32 WIndows 2003 server.
No problem. My user name in Latin characters.
Seems like username is in locale-specific symbols and one of shell32 callbacks receives utf8-encoded user home directory name.
I even created a user "Вася" and tried to execute example from desktop of that user and from console with active home (c:\Documents and Settings\Вася)
||Under win10 with Cyrillic profile name - no problems.|
||The error raise if run Win32/i386 application on Win64 os.|
I did testing i386-win32 binary on x86-64 win7 and win10.
Binary was compiled with FPC 3.3.1 SVN trunk.
||Did you use the DisableUtf8RTL define when you built the program?|
||I now installed the Win64 version - the error when opening remained consistent.|
The problem may be not in application, but in shell extensions (for instance Kasperski trojan installed on your system) calling dialog hooks which improperly handled.
Can you test on clean machine?
Can you list the DLLs loaded by your process?
||B.t.w. Why does the TOpenDialog try to open with Desktop as default folder (since you don't set that in your project)?|
Found suspicious place in LCL
FolderName := UTF16ToUTF8(DialogRec^.UnicodeFolderName);
FileNames := UTF16ToUTF8(DialogRec^.UnicodeFileNames);
if FolderName='' then
// On Windows 7, the SendMessageW(GetParent(Wnd), CDM_GETFOLDERPATH, 0, LPARAM(nil))
// at UpdateStorage might fail (see 0016797)
// However, the valid directory is returned in OpenFile^.lpstrFile
// What was the reason not to use OpenFile^.lpstrFile, since it's list
// of the selected files, without need of writting any callbacks!
// Check for DirectoryExistsUTF8(FolderName) is required, because Win 7
try to change/play here with encoding of FolderName var getting.
||Use Lazarus 2.0.8 + fpc 3.0.4 problem it is shown if run program use f9. If run program use explorer program work without error.|
||Mihail, so if you run the application without a debugger it works?|
This issue may be caused by gdb treating environment as local 8bt charset (the IDE uses utf8).
While this can be fixed (as long as all chars are from one locale only), the IDE would then need to be configured to know if the current gdb expects utf8 or not.
If the above is the case, then this may be a while.
For the time being, it might be best to install the package LazDebuggerFp, and configure (Tools > Options > Debugger) to use fpdebug.
I uploaded an old 7.3.5 https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2032%20bits/Alternative%20GDB/GDB%207.3.50/
that might (if I got the testing right) support utf8.
However it will have other issues that had been fixed in the meantime in gdb. I have not done any further tests to see how well it works in the IDE.
I am not sure what exactly makes some gdb work with utf8 and other not. From glancing at the gdb sources it might be that only gdb build under cygwin (or environments that are treated as such) will do utf8. (But even under cygwin it is in a conditional define, which I have not followed up any further)
|2019-10-17 10:44||Mihail||New Issue|
|2019-10-17 18:24||Bart Broersma||Status||new => feedback|
|2019-10-17 18:24||Bart Broersma||LazTarget||=> -|
|2019-10-17 18:24||Bart Broersma||Note Added: 0118645|
|2019-10-18 02:50||Mihail||File Added: errOpenDialog.zip|
|2019-10-18 02:50||Mihail||Note Added: 0118656|
|2019-10-18 02:50||Mihail||Status||feedback => new|
|2019-10-18 13:42||Bart Broersma||Note Added: 0118659|
|2019-10-18 16:43||Anton Kavalenka||Note Added: 0118660|
|2019-10-18 16:50||Anton Kavalenka||Note Edited: 0118660||View Revisions|
|2019-10-18 18:53||Anton Kavalenka||Note Added: 0118666|
|2019-10-21 06:35||Mihail||Note Added: 0118745|
|2019-10-21 08:03||Anton Kavalenka||Note Added: 0118746|
|2020-05-14 18:46||Bart Broersma||Relationship added||has duplicate 0037063|
|2020-05-14 18:47||Bart Broersma||Note Added: 0122798|
|2020-05-18 03:25||Vitaly V Gorbukov||Note Added: 0122896|
|2020-05-18 10:50||Anton Kavalenka||Note Added: 0122899|
|2020-05-18 20:15||Bart Broersma||Note Added: 0122909|
|2020-06-01 16:17||CudaText man||Note Added: 0123165|
|2020-06-16 06:31||Mihail||Note Added: 0123449|
|2020-06-16 08:07||Dmitry Boyarintsev||Note Added: 0123451|
|2020-06-16 08:11||Mihail||Note Added: 0123452|
|2020-07-14 22:58||Dmitry Boyarintsev||Relationship added||related to 0037349|
|2020-07-15 20:50||Martin Friebe||Note Added: 0124062|