On Tue, 22 Nov 2005 19:35, Michael Jung wrote:
> Are you saying that on an asian system CP_ACP is actually a double byte
> encoding? Is anybody on the list using an asian locale on her system? Does
> it break the unixfs extension?
The Chinese, Japanese and Korean code pages ( 932, 936, 949 and 95
Hi,
On Monday 21 November 2005 18:38, Alex Villacís Lasso wrote:
> I was rather hoping for an explanation of which is the "correct"
> behavior for an UTF-8 locale:
Sorry. I guess I'm not that competent when it comes to character encoding
stuff. But then, Alexandre and Troy already answered your
On Tue, 22 Nov 2005 06:54, Alexandre Julliard wrote:
> 2) is the right behavior. The A functions always return strings in the
> Ansi codepage, not in the Unix one. There is no Windows locale that
> uses UTF-8 as Ansi codepage, so if a UTF-8 string is returned to the
> application that's a bug.
Thi
Alex Villacís Lasso <[EMAIL PROTECTED]> writes:
> 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) Op
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
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 b
Consider the following MSVC program:
- cut -
// PruebaOpenDlg.cpp : Defines the entry point for the console application.
//
#include
#include
#include
#include
int main(int argc, char* argv[])
{
OPENFILENAME ofn; // common dialog box str
