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

[Alex Villací­s Lasso]

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