TC7.50pb2: special chars not displayed in lister (ANSI/HEX)

[wanderer]

Open a file in Lister. The file must contain special characters in it (i.e. any text file with CRs and LFs).

Change viewing mode to Binary (2) or HEX (3) and Encoding to ANSI (it happens with custom code pages too).

In "As configured for current font" encoding, little black boxes are shown for characters that cannot be displayed (i.e. CR, LF, etc). In ANSI mode though (or any other custom code page) nothing is displayed. In HEX mode, this makes the right part of the window appear unjustified.

This does not happen in TC7.04a but since then, many things have been changed in Lister...

Tests performed under WinXP-SP3 (32bit).

[ghisler(Author)]

Here is what happens:

Hex and Binary modes:
Lister shows the little black boxes if the reported character width is wrong for a fixed width font. For a variable width font, Lister shows boxes only for characters with a width of 0.

In Text mode, Lister always shows the characters unchanged.

This is by design. Does any of your findings differ from the above behaviour?

[wanderer]

Lister shows the little black boxes if the reported character width is wrong for a fixed width font.

I'm guessing the way it looks now in TC7.5, it's not how it is supposed to look. Anyway, a picture will probably be more helpful.

[karlchen]

Hi, Wanderer, hi, Christian.

Is the reported behaviour not the same behaviour which was reported for T.C. 7.02 a long time ago, here: Display bugs in Compare ?

Kind regards,
Karl

[wanderer]

Is the reported behaviour not the same behaviour which was reported for T.C. 7.02 a long time ago

Hello Karl.

I'm not sure. TC7.04a works just fine for me. What i'm reporting seems to be something new, introduced in TC7.5.

I'm using the fixedsys font in Lister for ANSI encoding. I tried using Courier New, as Christian mentions in the link you provided but there is no difference.

Some additional info: When i open Lister, "As configured for current font" encoding is selected. As soon as i change it to ANSI, i notice the problem i'm reporting.

After some more testing: it seems to happen with every type of encoding except "As configured for current font" (just tested this under Win2K-SP4).

[karlchen]

Hi, Wanderer.

What i'm reporting seems to be something new, introduced in TC7.5.

Well, the lister menu item "Encoding" has been introduced in T.C. 7.50 and does not exist in 7.04a. This is true. So you are right. I'd say that the linked thread was about a somehow similar problem, yet not about the same problem that you reported.

it seems to happen with every type of encoding except "As configured for current font" (just tested this under Win2K-SP4).

I can confirm this, well, partially:

• Reproduced the described behaviour on Windows XP Prof SP1/SP2, 32bit, ger
• Cannot reproduce the described behaviour on Windows Vista Home Premium, 32bit, ger

On Vista, lister displays a dot for each non-printable character like CR, LF, tab, etc., independently of the selected encoding.
Lister has been set to use the "default font" for "ASCII", "ANSI" and "variable width". So it will be the Vista font which replaces non-printing characters by dots and not by little squares.

Testfile used in all cases: the "tasten.txt" file (German version of "keyboard.txt" in the folder "%COMMANDER_PATH%)

Kind regards,
Karl

[white]

Open a file in Lister. The file must contain special characters in it (i.e. any text file with CRs and LFs).

Change viewing mode to Binary (2) or HEX (3) and Encoding to ANSI (it happens with custom code pages too).

In "As configured for current font" encoding, little black boxes are shown for characters that cannot be displayed (i.e. CR, LF, etc). In ANSI mode though (or any other custom code page) nothing is displayed. In HEX mode, this makes the right part of the window appear unjustified.

Confirmed. Menu option Options/ANSI (Windows charset) checked and menu option Encoding/ANSI (local code page) (0) checked.

This does not happen in TC7.04a but since then, many things have been changed in Lister...

It does not happen in TC7.04a? It was not possible in TC7.04a to choose both options mentioned above.

[karlchen]

Hi, white.

On which Windows version did you reproduce the display problem?
I am asking, because I can reproduce it on Windows XP, but not on Vista. (see my previous post)

Cheers,
Karl

[white]

On which Windows version did you reproduce the display problem?

Windows 98 SE.

[karlchen]

Hi, white.

Thanks for revealing the Windows version.

For the moment the issue has been reproduced on
+ Windows 98se
+ Windows 2000 SP4 Rollup1
+ Windows XP Sp1, Sp2, Sp3
+ Windows 2003 Std SP2, 32bit/64bit

The issue could not be reproduced on Windows Vista.

Hopefully I will not forget to check out what lister looks like on Win2K SP2 Rollup1 and on Windows 2003.

Cheers,
Karl
--
<edit>
Thanks to Wanderer's reminder below and based on my own tests on Win2003, the list above has been completed, Win2K and Win2003 have been added.
</edit>

[wanderer]

Hi Karl

Hopefully I will not forget to check out what lister looks like on Win2K SP2 Rollup1 and on Windows 2003.

After some more testing: it seems to happen with every type of encoding except "As configured for current font" (just tested this under Win2K-SP4).

That is Win2K-SP4 Rollup1.

[karlchen]

Hi, Wanderer,

right, you had stated before that you had used Win2K SP4.
The list in my previous post has been amended.

What is left is: Windows 7 and Windows Server 2008. No reports for these versions so far. Yet, I bet they will behave like Vista.

Cheers,
Karl

[ghisler(Author)]

I could reproduce and fix it now, thanks for all your help! It happens in this constellation:
1. ANSI mode, binary or hex view
2. No custom codepage chosen -> TC uses Windows GDI to show text
3. Line breaks (CR/LF) have standard widths, so TC does not replace them by dots
4. Switch to a user-defined encoding, e.g. Cyrillic -> TC uses Uniscribe now for text output
5. Uniscribe doesn't display line break characters, they have width 0, but TC still assumes that they have the correct width from measuring it with GDI functions.

[wanderer]

Great. Thanks for the fix.

[karlchen]

Hello, Christian.

I would like to confirm that the issue has been solved by T.C. 7.50 PB3.

Tested it on these platforms:
+ Windows 2000 SP4 Rollup1, 32bit
+ Windows XP Sp2, 32bit
+ Windows 2003 Std SP2, 32bit/64bit
+ (Windows Vista had not been affected.)

Kind regards,
Karl
--
<edit>
Removed the string "Wanderer's statement" from the first sentence. Looks as if I had overinterpreted your previous reply.
</edit>