tc7.5b8 weird chinese symbols in lister menus

[brotbuexe]

see screenshots.

on win7 rtm x64.

Image: http://www.brotbuexe.de/pics/totalcmd/greenshot_2009-07-31_22-48-31.png
Image: http://www.brotbuexe.de/pics/totalcmd/greenshot_2009-07-31_22-48-46.png

it changes from the first to the second shot when i moved the mouse over it.

Image: http://www.brotbuexe.de/pics/totalcmd/greenshot_2009-07-31_22-48-54.png

[j]

Confirmed! I wanted to report this earlier but forgot about it. Now I looked a bit into it:

This happens, when a custom language file is used (like the Extended English menus).

The culprit is a "\t" in a definition, like in:
5922="&Find\tCtrl+F / "

The tab is actually used but then an invalid character is placed after the string and before the hotkey that is appended

A guess: Off by one as the \ is counted as character when appending but in reality is already translated into 0x09.

[petermad]

This happens, when a custom language file is used (like the Extended English menus).

If that is the case then try to remove the 2nd line:

Code: Select all

codepage=1252

from the .lng file.

[j]

If that is the case then try to remove the 2nd line:

Code: Select all

codepage=1252

from the .lng file.

Unfortunately this does not help here.

FWIW: When using Windows XP there is only a single square instead of a massive garbage sequence.

[petermad]

What is your system setting for language?

Does it also happen if you use for example wcmd_dan.lng ?

[j]

What is your system setting for language?

English version of both Win7 x64 and XP.

Does it also happen if you use for example wcmd_dan.lng ?

Yes, as it does with wcmd_eng.lng when adding a \t to some menu entry and it naturally gets worse when adding more \t.

I just wonder why you don't have any issues

[ghisler(Author)]

Unfortunately I cannot confirm it. I replaced line 5922 in the German lng file with this one:
5922="&Find\tCtrl+F / "

But it showed up just fine in Lister's main menu.

Where can I find a translation causing this problem?

[j]

Unfortunately I cannot confirm it. I replaced line 5922 in the German lng file with this one:
5922="&Find\tCtrl+F / "

But it showed up just fine in Lister's main menu.

Where can I find a translation causing this problem?

That is strange, the language file really does not matter here.
I tried it with the WCMD_DEU.LNG by just replacing 5922 with the line above and Windows 7 x64 displays alot of garbage and a (mostly) clean and fresh XP and TC 7.5b8 installation gives me a square.

Windows 7 looks just like the screenshots brotbuexe posted.

Windows XP looks like this: http://i30.tinypic.com/vglg9g.png

Edit: And multiple \t result in: http://i27.tinypic.com/2ezs7iv.png

Edit2: Ah, I have another guess what the problem might be seeing the multiple \t. Does the "F7" prepend an extra \t without checking if there is already a \t in the string?

[petermad]

Ah, I have another guess what the problem might be seeing the multiple \t. Does the "F7" prepend an extra \t without checking if there is already a \t in the string?

It must be more than that, because it works allright with for me and Ghisler with the extra \t in the string - besides the hardcoded \t.

Could it be a font problem? - what is your system font for menu elements?

Does it also happen with previous TC 7.50 betas - or with TC 7.04?

[j]

Could it be a font problem? - what is your system font for menu elements?

The defaults, that is Tahoma under XP and Segoe UI under Windows 7.

Does it also happen with previous TC 7.50 betas - or with TC 7.04?

It seems to exists before 7.5, 7.04a has the same behavior.

You probably have a font set where the tab character is not visible at all.

I bet that Windows 7 can't handle multiple tabs in a menu entry at all...
EDIT: Indeed, creating a small MFC test with a menu entry with multiple \t also brings nice garbage.

[petermad]

I have tried with both Tahoma and Arial under win XP - no problems here.

[j]

Well it's confirmed on atleast three different machines and two different versions of Windows so I guess this should be fixed - either by prohibiting \t in the language file or checking for it in TC and removing it there accordingly.

[ghisler(Author)]

Thanks for your investagations - it's probably best to simply cut the text at the second \t if there is any...

[petermad]

2j
Could you tell me whether you have problems in:
1. The menu that pops up when you right click a folder tab.
2. The menu that pops up when you right click a search result in Synchronize directories.
3. The menu that pops up when you right click an empty area in the button bar.

Could you please try this whith both the internal English language, the German and the Danish language file. Especially this line: 6268="&Sammenlign venstre og højre\tCtrl+F3 / Dobbeltklik" in the Danish right click menu in the Synchronize tool has my interest.

I am interested in finding out whether it is the / in menus, where this / isn't there in the internal dialog, or whether it is the use of \t where they are not used in the internal dialog - and whether it is only in Listers menu or also in these other 3 menus.

Finally, if you are up to it, maybe you could check if there are any problems with these items in the main menu:
English: "Mark" -> "Restore Selection\tNum /"
Deutch: "Markieren" -> "Auswahl wiederherstellen\tNum /"
Dansk: "Vis" -> "Opdater vindue\tF2 / Ctrl+R"

[j]

As said, this has nothing to do with the / but only with \t and it also occurs with a standalone MFC application. So for that matter it is not directly the fault of TC. It is also understandable that multiple \t in a menu entry lead to undetermined behavior, as only one \t is well defined as a separator between the label and the hot key(s).

At the moment, Total Commander appends a "[face=courier]\tHOTKEY[/face]" for several entries in the Lister (the main menu has a proper definition) as such, when the language file contains a "[face=courier]Label\tOTHERHOTKEY / [/face]" it results in "[face=courier]Label\tOTHERHOTKEY / \tHOTKEY[/face]", where it should be "[face=courier]Label\tOTHERHOTKEY / HOTKEY[/face]".

Thanks for your investagations - it's probably best to simply cut the text at the second \t if there is any...

I think it might be better to check if there is a \t in the string when appending the hotkey.
So if the \t is missing, append it and then the hotkey, otherwise just append the hotkey. This way, custom languages can define static hotkey labels and definitions like the Extended Menu could work without any changes.
Multiple \t for a menu entry in a language file can be considered as erroneous and the language file should be fixed.