I guess I'm not understanding the purpose of the filte transfer pane in relation to directory monitor. Why do we need two separate functions? Instead, why not have a single monitoring function that can monitor any path, whether it's a directory, a file, or a file name pattern. If it's a directory path, then you're monitoring the entire directory, so all files in the directory would be listed in the monitor. Now, if you want to exclude a particular file, or a particular sub-folder from monitoring, you coud click on the "eye" icon for that path. The path/file would still be visible in the pane, but there would be a slash through the eye or something, to indicate that it's not being monitored. In fact, in the file transfer pane, each file has an eye icon, which I assumed was for this exact purpose, yet it seems to be non-functional, so I don't understand why it's even displayed.

This approach would give you a live view of whatever you're actually monitoring, automatically updating as files are added or removed. If a new file appears that matches the pattern, it might be displayed in bold type for a period of time, to alert the user that a new file is being monitored. If a file is deleted, it could be displayed dimmed out, as we previously discussed, and perhaps after a specified amount of time, it could automatically disappear from the list. That way, you could see exactly what files are in the monitoring path, which ones are being monitored, which ones have recently appeared and which ones were recently deleted. The current approach seems cumbersome and redundant, in that you have two separate monitoring functions that sort of interact with one another, but not really. For example, If I delete a file, I want it removed from the file transfer pane, because it makes no sense to display a file that no longer exists However, if the file is later recreated, it should reappear automatically. The current behavior seems non-intuitive to me.

One problem to consider is this: open a log file, terminate monitoring, write some entries to the log file, roll the log file, start monitoring.  What is the state of the log file you are viewing?  Do you have a complete list of log entries in the time range shown?  I believe that you may end up with a corrupted view.

For this reason, it doesn't really make sense to 'restart monitoring' on a log file.  It could potentially lead to a lot of confusion for the end user.  Also, local files do not have file transfers and do not appear in the 'monitoring' pane.

The directory monitor is responsible for opening all matching files.  An opened file may be monitored.  So the relationship is Directory -> File -> Monitor.  If monitoring is terminated, it can be restarted by refreshing the file with F5.

Does that make sense?  It may help if you can give me an idea of the use case you are trying to achieve.

If I delete a file, I want it removed from the file transfer pane, because it makes no sense to display a file that no longer exists

As previously discussed, the log file in the view should display all log entries since monitoring started.  If a file is deleted, it can be recreated.  Therefore, monitoring should not be terminated.

This is related to the delete feature we've been discussing. Currently, I'm performing the steps manually and not getting the expected outcome.

I'm not suggesting to restart monitoring. I'm suggesting that when you delete a file, remove it from the file transfer pane, and remove it from the log files list, that it should be as if it never existed in the first place. Therefore, if the file is later recreated, the directory monitor should pick  it up and add it to the file transfer pane as a new file.

Honestly, this isn't a huge deal. As you mentioned, it can be refreshed manually. However, it's nicer when things just work without manual intervention. My main point is that when you physically delete a file, remove it form the file transfer pane and remove it from the log files pane, there should be no memory of the file. If it reappears, it should be treated as a new file.

Thanks for the clarification.  I think there are a couple of work items outstanding on this issue - including a command to delete the file and improved visual indicators.  Let's get the next version out and go from there.

Hi Brad,

I just wanted to let you know that we have now released LogViewPlus 2.5.34 as a BETA release.  This release includes a new 'File System' context menu which consolidates file system actions and adds a new 'Delete' command.



I think the 'File System' context menu approach makes the user intent clear while also giving room to expand in the future.  Please let me know if you have any comments or suggestions.

Hope that helps,

Toby

Thanks, Toby, the screenshot looks great!

I noticed the installer wants to install it into Program Files (x86), while the previous version installed into the x64 directory. Why is that happening? I don't want to end up with two different versions installed in different directories.

The 'Program Files' target has changed in this release.  This is an unfortunate side effect of migrating to an admin-free installer.  You will need to manually uninstall the previous version before upgrading.

Note that LogViewPlus will still run as a 64-bit program on a 64-bit OS.

The new Delete option works well. It would be nice if it supported deleting multiple files via shift-select. I had to clean out like 20 files today. I tried the Delete on one and it worked great. Then I tried shift-select and it was no-go, so I used the Open Directory option to open the file manager. I was able to shift-select and delete them using the File Manager, but of course, when I returned to the main window, the files were all still listed there, and lots of blank entries in the monitor pane.I was able to clean everything up by closing and re-opening the workspace, but it doesn't seem elegant.

Thanks for the feedback Brad.  

Shift-selecting multiple log files is something that has been on our list for awhile as it would make tasks like merging easier.  Once we get this implemented, supporting the Delete option makes sense.

For this release, I will take a look at handling the delete events generated in the Log Explorer more elegantly.  It makes sense that files removed via Log Explorer are also removed from the view.

Hi Brad,

We have just released LogViewPlus v2.5.35 as a BETA release. This release tracks file deletions made from the Log Explorer and updates LogViewPlus accordingly.

Hope that helps,

Toby