Prev: Remote reboot
Next: Delete Printer
From: Floptimize on 12 Sep 2005 14:08
Hello,

This post is regarding a problem I am experiencing opening files with
Hungarian letters in the file name. I am using CreateFile with UNICODE
and _UNICODE defined in my VC6.0 projec, running Windows XP Pro, with
U.S. English code page.

This is my test app:

int _tmain(int argc, LPTSTR argv[])
{
TCHAR szText[MAX_PATH + 1];
DWORD dw = 0;
HANDLE hf = INVALID_HANDLE_VALUE;

_tcscpy (szText, _T("E:\\tmp\\Hungarian\\bflõuzáékötyy.tga"));
hf = CreateFile (szText, GENERIC_READ, 0, NULL, OPEN_EXISTING, 0,
NULL);
if (hf != INVALID_HANDLE_VALUE)
CloseHandle (hf);
else
dw = GetLastError ();

return 0;
}

I assure you the file actually exists on my drive, however the open
fails and GetLastError() returns 2, ERROR_FILE_NOT_FOUND.

The problems seems to be with the letter õ, of the name. Other tools
such Gimp (image processing software) also cannot open the file.


How can I get around this limitation, please?

From: Lucian Wischik on 12 Sep 2005 14:46
"Floptimize" <bikermike(a)gmail.com> wrote:
>The problems seems to be with the letter ý, of the name. Other tools
>such Gimp (image processing software) also cannot open the file.

I think you should try FindFirstFile/FindNextFile to iterate over the
files in the directory, and do _tcscmp to see if any of them match the
string you supplied. This is just a test for you the developr to do,
not something that goes into the finished product. Maybe unicode has
multiple glyphs for o-twiddles and you have the wrong one?

--
Lucian

From: Lucian Wischik on 12 Sep 2005 15:20
"Floptimize" <bikermike(a)gmail.com> wrote:
> _tcscpy (szText, _T("E:\\tmp\\Hungarian\\bflýuzýýkýtyy.tga"));
> hf = CreateFile (szText, GENERIC_READ, 0, NULL, OPEN_EXISTING, 0,
>NULL);

One other possibility is that the text-editor/compiler you're using
simply don't work well with unicode characters. You should try writing
that text-literal using escape-sequences, so that your program source
code is pure 7bit ascii.

As for why GIMP doesn't handle it? -- I think that most open-source
software that started in linux is bad at unicode. For instance,
Firefox won't File>Open a filename with japanese characters in it.

--
Lucian

From: Floptimize on 12 Sep 2005 15:30
Thanks for reply, I am in the process of experimenting with
FindFirstFile/Next. Good suggestion.

Regarding the alt-sequence suggestion, well unfortunately, that's
exactly how I entered the filename to begin with into the VC6.0 editor.

I'll followup shortly.

Thanks

From: Floptimize on 12 Sep 2005 15:45
Very interesting!

The FindFirstFile call resulted in loading the cFileName member of the
WIN32_FIND_DATA struct with the following contents:

62 00 66 00 6C 00 51 01 75 00 7A 00 E1 00 E9 00 6B 00 F6 00 74 00 79 00
79 00 2E 00 74 00 67 00 61 00 00

In the variable window it shows: - cFileName 0x0012fb48
"bflouzáékötyy.tga"

However the o is stored as 51 01 in UCS2.

The file on disk in Windows Explorer looks like this
"bflõuzáékötyy.tga".

Now my next complexity is finding a way to make all this work for me in
my code.

Hmm I'm jammed on this one because, we are using a VB client app which
users can select filenames. The app interfaces with ATL code that
takes BSTRs arguments for filenames, and the content of the filename is
mangled before the ATL code gets it. Looks like we'll have to change
the parameter type for filenames to byte arrays (VT_ARRAY | VT_UI1) or
some other type? Seems that the VB StrConv function may help us.

Any suggestions?

 |  Next  |  Last
Pages: 1 2 3
Prev: Remote reboot
Next: Delete Printer