GetOpenFileNameA has trouble with UTF-8 locale and UTF-8 encoded pathname

Alex Villací­s Lasso a_villacis at
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.
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