I have a view that includes a PID column from a linux log file that is populated using the %s feature in the pattern parser. That part is fine. The PID values are clean, just the numbers, no whitespace or other characters.
I would like to filter the view to PIDs using the autofilter, e.g. > 1000, but it doesn't work. Maybe because LVP does not support fields as numeric, only fields as text for the autofilter.
If I have a file with rows that include PID values 269 and 1322 I get the following results
PID = 269 - I get the rows with PID 269
PID = 1322 - I get the rows with PID 1322
PID > 1000 - I get the rows with both PID 269 and 1322
The first 2 results are as expected, the 3rd result I just want 1322.
Is there anyway to achieve this?
Thanks in advance
Support for custom numeric fields in autofilter
Posted on Sep 15, 2023 at 4:18 AM
Posted on Sep 15, 2023 at 12:37 AM
I had an 'aha' moment when I found the advanced specifiers and tried %t for thread, thinking it would be treated as numeric but I get the same result.
Posted on Sep 15, 2023 at 7:03 AM
In general, LogViewPlus tries not to make assumptions about the underlying data type and sees all data as a string. This is to support new data coming in (tail) while also keeping the program easy to use.
The auto-filter functionality is an example of this and the issue above highlights some of the shortcomings of this approach. Unfortunately, this tool is managed by a third party and we will not be able to address this issue in the short term. The auto-filter command also has other limitations and is not intended to be a full replacement for filters.
In other parts of the application we do attempt to determine a data type based on the user action. One example of this is our SQL engine.
So, instead of using an auto-filter, I would recommend using a SQL Filter for this task. Something like:
Hope that helps,
Toby
The auto-filter functionality is an example of this and the issue above highlights some of the shortcomings of this approach. Unfortunately, this tool is managed by a third party and we will not be able to address this issue in the short term. The auto-filter command also has other limitations and is not intended to be a full replacement for filters.
In other parts of the application we do attempt to determine a data type based on the user action. One example of this is our SQL engine.
So, instead of using an auto-filter, I would recommend using a SQL Filter for this task. Something like:
SELECT * FROM CurrentView
WHERE PID > 1000Hope that helps,
Toby
Posted on Sep 15, 2023 at 7:25 AM
That works.
Too easy! Thanks.
Too easy! Thanks.
Posted on Sep 15, 2023 at 7:26 AM
Glad that helped - thanks for letting me know! :)
This topic is closed and cannot receive new replies.