Total Commander

Windows 8.1, TC 9.12 64-bit

This is common with log files. The log file stays open, lines are appended and flushed. The text is in Unicode (UTF-16 LE with BOM), if it matters at all.
Probably this would not be seen with ordinary static files.

Open file, press End
An example of the last line.

Reopening the file would not help - until file gets more lines.
Other navigation methods make no difference (Ctrl+PgDn).

Obviously, the last line is barely readable, and adding about half a line of safety space might help.

browny,

An example of the last line.

... is missing.

Roman

Thanks; fixed the picture link in the opening post.

2browny

Open file, press End

Do you perhaps mean Ctrl+End (to go to the last line) - or do you really mean to go to the end of the current line? When you write "Open file", I assume you mean open file with Lister...

Anyway I cannot reproduce it (in Lister using Ctrl+End) with TC's own log files (which here is written in UTF-8). Which log-files are you referring to?

Does it happen for you with any size of the Lister window? What font-setting are you using in Lister for this file type?

petermad,

Do you perhaps mean Ctrl+End (to go to the last line) - or do you really mean to go to the end of the current line? When you write "Open file", I assume you mean open file with Lister...

... with the cursor being turned off.

Roman

petermad wrote:Do you perhaps mean Ctrl+End

End works for me, and as was written, whatever method gets to the end of file.

When you write "Open file", I assume you mean open file with Lister...

The first word in topic title suggests that idea.

Settings: autodetect and default fonts.

Not sure if this is related: after opening file, the lowest line in Lister's window is visible only partially, like in the example picture. But that line is not the last line in file.

This has been a long-standing issue in TC and it kind of annoys me, too. IIRC it was discussed in the past, but I don't remember what Ghisler said about it and how he explained it (if he did).

And yes, I have Lister's cursor always turned off, only rarely switch it on when I need it.

Regards
Dalai

2Hacker

... with the cursor being turned off.

Arh - always forget about that option But in my defence - cursor being on is the default setting.

2browny

The first word in topic title suggests that idea

Oops again


But apart from that - even if I disable the cursor in Lister, I still cannot reproduce it.

Not sure if this is related: after opening file, the lowest line in Lister's window is visible only partially, like in the example picture. But that line is not the last line in file.

It doesn't matter whether I adjust Listers height, so that the last visible line when just opened is not cropped or not. In both cases the last line is shown whith at least one empty line beneath when I press End.

I can not make the log file work with Unicode - only with UTF-8 or ANSI- text - but that might be due to my Windows Locale. By default my TC saves the log file as UTF-8, but if I convert an existing log file to ANSI it works with that too, but not if I convert the file to Unicode or Unicode Big Endian - with Unicode new entries are shown in Chinese (it looks like).

I have also testet with a clean ini file and with Windows 8.1, and still cannot reproduce the problem.

2browny
Do you use any DPI-scaling?

petermad wrote:I still cannot reproduce it.

That was another attention test.
It was said being common.
Not every time, in other words. There is a fair chance to catch the problem if the file is updated frequently.

petermad wrote:Do you use any DPI-scaling?

No DPI scaling.

Maybe lister does not take into account the horizontal scrollbar; that would explains why lowest line is cropped, and the same happens with the last line in file

There is a fair chance to catch the problem if the file is updated frequently.

I have tried at least 50 times after file update without "success"

I guess it must have to do with the Unicode (UTF-16 LE with BOM) encoding, which I cannot duplicate - have you done anything special to have the log-files in that format?

My TC writes a blank line in the end of the file - does yours?

It was said being common.

I can find these:

http://ghisler.ch/board/viewtopic.php?p=178372#178372
http://ghisler.ch/board/viewtopic.php?p=162954#162954

but they ar caused by only very long lines or word wrap being on - I don't think either is the case here - from your screnshot you obviously don't have word wrap enabled, since you have a horizontal scrollbar, and I doubt that any file operation can result in a 4000 character long line.

UTF-16 LE is Windows' native, no coversion needed.

The issue also exists with wrapping on.

Lines could be longer than 500 characters, still far from 4000 characters limit.

Cautiosly dragging bottom of the window in tiny increments allows to see more of the line; and there might be yet another one below.

Which means, that probably the followin happens:
1) Lister gets file size, then reads files sequentially until end of file condition
2) Lister gets more data than expected, because file size was either reported incorrectly due to delayed update, or size was invalidated with file write(s)
3) window size is not a multiple of line height, hence this display issue with additional lines

Maybe Lister should readjust file size and line count according to actually received data.
Or cheat a little by tweaking window height to make it look right.

UTF-16 LE is Windows' native, no coversion needed.

Hmm, as I wrote - here by me, when TC generates a new log-file from scratch, it is in UTF-8 - it even says so inside the file:
"19-12-2017 10:54:10: Program start (username/computername) UTF-8"

And the file is also recognized as UTF-8 if I check the format in Notepad or in Lister.

petermad wrote:

UTF-16 LE is Windows' native, no coversion needed.

Hmm, as I wrote - here by me, when TC generates a new log-file from scratch, it is in UTF-8 - it even says so inside the file:
"19-12-2017 10:54:10: Program start (username/computername) UTF-8"

And the file is also recognized as UTF-8 if I check the format in Notepad or in Lister.

Well, eMule log files are hardly comparable with TC log files, or...?

Well, eMule log files are hardly comparable with TC log files,

OK - now everything is much clearer - you never stated that it was not TC's log files you were talking about...