Unicode folder name

[Namume]

i cannot change directory to some folders with Unicode name, for example, 李敖 (\u674e\u6556), and some rmvb files also.
dont tell me to switch to Chinese/Japanese locale...

[Flint]

Namume

dont tell me to switch to Chinese/Japanese locale...

If you use TC 6.xx, this should not be necessary. I use, for example, Russian locale, I created the folder with the name you specified and opened it in TC - all worked successfully.

AFAIK, TC works with such folders by their DOS name. Don't you have disabled DOS-name creating option? Look the following option in the registry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
NtfsDisable8dot3NameCreation - it should be absent or have value 0.

Also try please to type dir /X - it outputs the files/folders names with their DOS-names. What does it show for your 李敖 folder?

[Sheepdog]

i cannot change directory to some folders with Unicode name, for example, 李敖 (\u674e\u6556), and some rmvb files also.
dont tell me to switch to Chinese/Japanese locale...

Create a button with command "cm_SwitchLongNames" and switch to the 8.3 Display mode of TC. Then you'll be able to switch into this folder.

sheepdog

[ghisler(Author)]

Folders with Unicode names do not work in TC if they do not have a valid DOS name. This can happen if you create such a folder and then change locale. Example: You create a Russian subdirectory with Russian locale, and then switch to English locale. The folder is then inaccessible to all ANSI programs, and also to all DOS programs.

Solution: Rename the folder to an English name, and then back to its original name. This will give it a valid DOS name.

[djet]

Too bad that in year 2005 TC is still not supporting Unicode and isn't fully transparent to the file system. I have to use Explorer to navigate some folders with Unicode characters. Neither I want to enable 8.3 filenames generation as it degrades performance as MS experts wrote @ TechNet.

[KevinMo]

I wish TC could have full unicode support as well.
Unfortunatly, Mr. ghisler(Author) said Delphi 2.0 environment doesn't support unicode, and he has to write it himself, hence only parts of TC features have unicode support yet. It must be tons of job...

[ghisler(Author)]

The main problem here is that the current path is not unicode, and it is used in many 1000 locations in the program. Converting them all to Unicode would take months to complete, in which I could not add any other functions at all. It would also make TC incompatible with Windows 9x/ME if I didn't implement everything twice (which is currently the case for those function which do support Unicode).

[Lefteous]

2ghisler(Author)
Is it possible to create two versions where a build option sets if a unicode version should be created or not?
Is there a string type comparable to TCHAR in Delphi?
This would make things easier in many (of course not all) cases.

[ghisler(Author)]

No, there is no TCHAR in Delphi, sorry. And two different versions would not be a good idea either.

[Flint]

ghisler(Author)

It would also make TC incompatible with Windows 9x/ME if I didn't implement everything twice

In MS Visual C++ there is a very good trick: a type TCHAR that is preprocessed either as usual char or as wchar_t - Unicode (wide) char, depending of whether the preprocessor variable _UNICODE defined or not. Also all necessary WinAPI functions are compiled as (for example) MessageBoxA or MessageBoxW depending on the same _UNICODE variable. This allows to create two-platformed programs without any trouble. It is only needed to compile the program two times: with _UNICODE and without it (if you wish, I can create a small simple example).

Unfortunately, I'm not familiar with Delphi, but maybe, it's possible to use something similar there?

Added:
Sorry, I was typing too slow...

[Lefteous]

2ghisler(Author)

No, there is no TCHAR in Delphi, sorry.

What a shame! Not even in the latest version?

And two different versions would not be a good idea either.

I'm not really sure. I guess you agree that it would be easier for you.
In addition a unicode version would be faster (no/lesser string type conversions) and smaller (no ansi stuff where it's not required).
For a user it could be a problem if a mobile unicode version should be started on a Win9x system...