The Previous / Next methods are off of the LogEntry - so there shouldn't be any problem with calling these methods from a custom filter using the existing interface.
However. It just occurred to me that the methods are working off of the current filter. In the case of a custom filter, they will be reading the previous entry in the filter. Next() will always return null because you haven't create a 'next' entry yet! :-) Not very helpful.
I think we will need to revisit these methods to accept an enum parameter:
Then, in your custom filter, you could call entry.Next(LookupSource.Parent)
to get the next log entry from the parent filter.
The initial call into Next or Previous basically does a scan of the view to find the entry and uses this as the starting point for the Enumerable. So, there may be a performance hit if a large filter were to scan each entry. For now, I would like to cross this bridge when we come to it. For example, it may be better to do a date search rather than a scan. I am trying to keep the API simple and I don't want to create a IFilter2 interface that does almost
the same thing unless a very clear need exists.
Also, keep in mind that filters need to work in tail mode. The method above would probably need to refresh the filter on every tail tick - which would not be ideal.
Hope that makes sense. I will get a new version of the API out before the release is moved out of BETA. I should have something for you in the next few days.