Mbcs

[leoleo]

Hi all,

I am working on various character sets in Windows. My application need to handle Japanese characters. In order,
_tcsXXX calls are used for UNICODE and MBCS compatibitity. I am working on Win2K with Japanese support enabled. I have created nested Jap directories for testing.
The problem is for _MBCS builds. The file operations fail, when a japanese filename is given as input.
Any suggestions to handle this?

-TIA

[mdmd]

The file operations fail, when a japanese filename is given as input.

What file operations fail ?
A Japanese filename is given as input to what ?
What are you doing to the string that was input ?

[leoleo]

The call _tfopen(...) fails, returning a null pointer. The build is MBCS in English(US) Windows 2000.

[Doctor Luz]

_tfopen is usefull when you want to compile both MBCS and UNICODE without making changes in your code

In MBCS when you do _tfopen, _fopen is called because you are in an MBCS application. This will not works with japanese file names.


I think you should call directly _wfopen instead of _tfopen when japanese file names are involved.

[leoleo]

Heres a code segment I use,

TCHAR szFilename[MAX_PATH] = {0}; //Jap string
FILE *fp = NULL;
.
.
.

#ifdef _MBCS
fp = (FILE *) _tfopen(szFilename,_T("rb"));
if(!fp)
fp = _wfopen((wchar_t*)szFilename,L"rb");
#else
fp = (FILE *) _tfopen(szFilename,_T("rb"));
#endif

But this also dint work ....

[Doctor Luz]

Perhaps the problem is the string where you store the file path

You store it in an array of TCHAR, however in MBCS TCHAR is char,

How do you obtain the japanese path name?

I think the szFileName sould be wchar_t[] for japanese files.

[leoleo]

Thts where the problem lies.I am in Normal windows(not Japanese) enabled for Jap locale. So the filename can be normal english strings or Jap strings. For normal strings char* would suffice.
Anyways things would go fine in a DBCS system like Japanese Windows, I suppose.
Btw, I get the filename through GetOpenFileName(...).

[Doctor Luz]

I think when you get the file name you obtaing basically a char[]. I think you should 'convert' it to double byte. May be MultibyteToWideChar( ) with the 932 code page can do this task, then you can pass the result as parameter in _wfopen() and see what happens.

In the FAQs (http://www.codeguru.com/forum/showthread.php?s=&threadid=231165) you have an example of usage if you have not used MultibyteToWideChar() never.

[leoleo]

I made the code like this,

#ifdef _MBCS
fp = (FILE *) _tfopen(szFilename,_T("rb"));
if(!fp)
{
MultiByteToWideChar(932, 0, szFilename, -1, wfilename, MAX_PATH);
fp = _wfopen(wfilename,L"rb");
}
#else
.
.
#endif

This dint work either.

[Doctor Luz]

The only thing I can say to you is to keep track of all the strings involved.

Debug your program and watch the strings contents.

Watch the string retrieved by GetOpenFileName and also what converstion MultiByteToWideChar does.

Perhaps GetOpenFileName does not obtains a good character string for the file name or the conversion to double byte is not well done.

sorry.

[leoleo]

The content of the string (szFilename) is just same to 'see', during debug, before and after the MultiByte..(...)conversion call.
Also CreateFile(...) API returns error code 123 which is ERROR_INVALID_NAME. I was just trying to simulate the Jap strings testing environment for the program. It may work fine with Japanese Windows.

-Thanks for your comments.

[Doctor Luz]

There are other conversion routines, mbtowc for example however I think the main problem is the file name. CreateFile uses a LPCTSTR with is (under MBCS) an LPCSTR, this is 8 bit characters.

[leoleo]

Actually it was some characters in the filenames and folders which led the file operations to fail. Avoiding such characters fixed the problem


Thank you.