Thanks again for your reply Mr Emura,
First of all, I am much aware of the delicate balance between functionality and simplicity in situations like this (I’m a developer myself), so I do indeed understand your hesitation about more functional but at the same time more complex solutions, just so you know.
About the “refresh” operation, it was apparently just a bad choice of words from my side (I didn’t know there was already another macro operation with that name). So let’s call it “ForceFilterExecution()” instead in my example above. All I meant was that one solution to the performance problem would be to make the default behavior of the “Filter()” command to never perform any filtering until the macro completely exits, and then offer a new macro function called something like “ForceFilterExecution()” that people could execute from the macro if they really need it to perform the filtering in the middle of the macro after all.
As a developer, I do understand though that there would be users that don’t know about this that would complain and report it as a bug etc. Therefore it might be best to just keep the “eeFindContinue” flag too, and make these two flags possible to use in the same call. As long as the “eeKeepPreviousFilterLevels” flag is included you keep any currently existing advanced filter levels, and as long as the “eeFindContinue” flag is included you don’t perform the filtering right after the call, but otherwise you do, just like it is currently implemented (a more descriptive name for the “eeFindContinue” flag would then perhaps be “eePostponeFiltering” or something like that).
The core problem with the current design is that both of these separate aspects (that is “keep pre-existing filter levels” and “perform filtering immediately after the Filter() call”) are forced into one single flag, which leaves some combinations of these two aspects impossible to implement, while still being possibly desirable (as in my exact situation for example).
Finally, you ask the following:
Can you please describe why you need the “eeKeepPreviousFilterLevels” flag instead of the eeFindContinue flag?
To answer this as efficiently as possible, I reply with the following counterquestion: If I want to make a macro that adds a new filter level to the currently existing filter levels at the point when the macro is executed (i.e. just like I describe that I want to do in my original post in this thread), how could I do this by only using the “eeFindContinue” flag? The first “Filter()” call in the macro will always clear all the current filter levels (since that flag only instructs what to do with the subsequent “Filter()” calls, but not the previous filter levels), while the “eeKeepPreviousFilterLevels” flag is able to specify also what to do with filter levels that already existed when the macro was executed.
Again, the real world situation I need to work with is the following:
I’m working with e.g. a web server log file, and I would then like to be able to select a certain string on some line in the text file, and then use a hotkey to execute a macro of mine that would add the selected string as a negative filter level in the Advanced Filter (and also immediately apply this newly extended advanced filter), thus removing all lines containing that string in the currently displayed file contents (that is, in addition to any previously filtered out lines, which should also remain removed). I would then continue to manually inspect the resulting contents, after which I would want to be able to repeat the same procedure again and again until all “uninteresting” log entry types have been removed, leaving me only with the few interesting “needle in the haystack” lines of interest.
Or to put it even more simply, I need to be able to:
- Add a new advanced filter level.
- Manually inspect the resulting filtered contents.
- Add a new advanced filter level on top of the existing ones (by calling my macro).
- Manually inspect the resulting filtered contents.
- Add a new advanced filter level on top of the existing ones (by calling my macro).
- Manually inspect the resulting filtered contents.
- Add a new advanced filter level on top of the existing ones (by calling my macro).
- … etc
But since there is seemingly currently no way to instruct the macro to keep any pre-existing macro levels when I call the “Filter()” function the first time in a macro, this is currently impossible. With the “eeKeepPreviousFilterLevels” flag it would be possible to do exactly that though!
In summary, a solution that would both close this functional void in the macro API while at the same time prevent any performance problems is to:
- Add a “eeKeepPreviousFilterLevels” flag.
- Keep the “eeFindContinue” flag (possibly even rename it to “eePostponeFiltering”, in order to make it more clear that it only controls that aspect and not the aspect of keeping pre-existing filter levels in any subsequent call), and also make it possible to use it in the same “Filter()” call as the “eeKeepPreviousFilterLevels” flag, as described in more detail above in this post.
And again, the core problem with the current design is that both of these separate aspects (that is “keep pre-existing filter levels” and “perform filtering immediately after the Filter() call”) are forced into one single flag, which leaves some combinations of these two aspects impossible to implement, while still being possibly desirable (as in my exact situation for example).