Hi Thomas,
Thanks for reporting these issues. Please note that I have renamed the subject of this ticket for clarity.
The mouse wheel should adjust the grid by 3-6 rows up or down. The number of rows is determined by the available screen space. It is best used for adjusting the current position rather than navigating.
I can see where it would take a while to scroll to the bottom of a log file, but I have been unable to recreate a significant delay when scrolling. It sounds like you stopped scrolling and LogViewPlus took several seconds to display the final position. Is this correct? This might have something to do with your particular log file (or how it is being parsed). It may also be machine or LogViewPlus version related.
Just to let you know, in my testing there is not much difference between scrolling in Notepad++ and LogViewPlus. I am testing with a 25 MB log file.
Also, for navigating around the log file, I would recommend using the navigation bar to the right of the scroll bar (usually color coded). Clicking anywhere in this area will take you to that part of the grid. Clicking the bottom of this area will scroll to the last log entry and enable tail.
Regarding the parsing issue, it is important to note two things:
1. LogViewPlus requires all log entries to have a timestamp.
2. A big 'final' log entry is an indication that LogViewPlus was unable to determine where this log entry ends. For the BasicParser this is rare. It is more common when a configured pattern is expected.
From your screenshots above, it looks like this log file does not have a date per log entry. If you could give me more detail, I would be happy to take a look. Please feel free to
contact me offline if you cannot publish the log details.
Hope that helps,
Toby