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.

Hi Tim - thanks for the suggestion.

I think this is a really good point and I can see the need for an additional configuration option. 

Last row selection generally very works well for enabling auto-scroll but, as your post highlights, the action is ambiguous.  Does the user want to enable auto-scroll or just look at the log entry?  LogViewPlus assumes auto-scroll, but it makes sense to have an override.  Note that with the override in place you will need to use the navigation bar or auto-scroll command to enable auto-scroll.  The End key is the keyboard shortcut for enabling auto-scroll.

Hopefully, we can turn this one around for the next release.  In the meantime, I would suggest double-clicking on the log entry when you want to maintain focus while navigating.

Thanks again,

Toby

Toby,

That double-click option works well.  Maybe we don't need the additional code.  This does seem to meet my needs even if it wasn't immediately intuitive.  I'll certainly accept a additional application customization option if you want to build it. However maybe all that can be avoided with some strategic documentation of this behavior.

For me at least, the last line selection and "other" line selection behavior difference was not immediately clear.  At first it did appear like a bug. It wasn't until I did a lot of digging and testing that I came to the conclusion that it was part of the design.  That said, until you told me about the double click, I didn't see a reasonable work-around to achieve the behavior/usability I wanted.

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

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.