GetOpenFileNameA has trouble with UTF-8 locale and UTF-8 encoded
pathname
Alex Villacís Lasso
a_villacis at palosanto.com
Mon Nov 21 11:38:33 CST 2005
Michael Jung wrote:
>Hi Alex,
>
>On Monday 21 November 2005 17:23, Alex Villacís Lasso wrote:
>
>
>>Whether GetOpenFileNameA returns a valid filename or not seems to depend on
>>the way the navigation is performed. That is, if the application starts the
>>Open File dialog from the current directory, and the user navigates by
>>directory change only, the invalid filename will be returned. However, if
>>the user first chooses a drive letter (such as F:) and then navigates from
>>there, the filename returned is a valid one.
>>
>>
>
>Seems to be a bug in the unixfs namespace extension. I will have a look into
>this as soon as time permits.
>
>Bye,
>
>
I was rather hoping for an explanation of which is the "correct"
behavior for an UTF-8 locale:
1) Open File Dialog returns an UTF-8 encoded string (visible to the
application, current behavior), and open-file functions expect UTF-8
2) Open File Dialog returns locale-encoded string (even in the UTF-8
locale), and open-file functions expect locale-encoding (as they do now)
Your comment strongly suggests (2) is the correct approach, but what
happens in East Asian locales? Or am I just demonstrating a lack of
knowledge on how non-UTF8 encodings work?
Alex Villacís Lasso
More information about the wine-devel
mailing list