https://www.logviewplus.com/forum/606/Last-selected-log-entry-in-filter-bug

I was hesitant to bring a thread from three years ago back to life, but I have been dealing with an aspect of this issue as described in the above thread and would like to get clarification on expected behavior.

First my scenario in LVP 3.0.22

My log files are Text files containing SMTP dialogs.  Each line is a record with Date, Time, Thread, Message.  However each SMTP session (e.g. Thread) can be intermixed line-by-line with other threads in the log file.  So in order to easily read each SMTP session without the noise of other threads, I open the entire SMTP Log file and immediately apply a template for all of the thread numbers  (Usually 0001 to 0030) 

Then I apply a second text filter off the main log file with the email address, subject, mail server, or whatever other data I was given to locate the email message delivery in question.  I then select the line with the matching data and finally select the corresponding thread view number (0001-0030).  This way, within seconds, I've found the exact 20 to 50 lines I need out of millions on our busy mail servers. It works great unless my text filter line is the last line of that view.

The problem is, I also Tail these logs for real-time support.  Which brings me to the fact that I don't agree with the present behavior of what happens when I select the last line of a filtered view and navigate to another view.  Moving between views seems like it should keep me on the line I've selected.  If I want to go to the end for tailing, I can just press CTRL-END.  The reverse however is not easy, I have to scroll through hundreds of thousands of lines, or setup a time filter, or turn tails on and off all day. 

If changing default behavior would break other people's use-case, can we at least be given an option for this alternate behavior under Settings --> Tail & Scroll Settings
[  ] When switching views, stay on selected entry
          (May require you to manually select the last entry in the new view in order to continuing tailing)

Thanks for your consideration.

Thanks for the update.  Glad to hear the work-around helps.

I will look into adding a new configuration option into the next release.  If this cannot be done in a relatively straight-forward way, then we will fall back to better documentation.

Hi Tim,

I just wanted to give you an update on this one.  We investigated this behaviour for the 3.1 release, but the implementation was too involved for a quick fix.  As a result of the investigation, we decided to have a completely separate auto-scroll implementation where auto-scroll could be controlled by selecting the last line (current behaviour), or an always on or always off check box (new behaviour).  Only one implementation would work at a time which could be controlled through settings.

We planned something like this...



Unfortunately, this brings up a lot of edge cases in the code which will create a large testing task.  The documentation also gets a little tricker as two sets of behaviour need to be explained when describing 'auto-scroll'.  As a result, we have decided to shelve this change for now.  We will pick it up again if there is more user demand for an alternative auto-scroll implementation.

We did update the documentation for v3.1, so hopefully that will provide some help for new users.

Thanks,

Toby

Thank you!  I greatly appreciate the "good ol' college try".  That said, I stand by my December 22 reply:

"...your choice: new code or additional documentation. I think either are acceptable options and neither are a wrong choice. "

The documentation change is perfect for me.  I've been using the double click option with great success.  I'm happy with the current functionality.