Closed RrnR closed 7 years ago
Very interesting, thanks for raising this issue! I am very curious want problem you are trying to solve?
First of all, we try to avoid filtering behaviour that is affected by their ordering. That said the coloring filters to allow you to define conflicting filters, so the order starts to matter.
Let take this bullets , one at a time:
drag and drop re-ordering: already possible, just drag the filter by its name and drop it anywhere, maybe it is not working for you? in that case, please add the result of run 'wmic os get Version, Caption, OSArchitecture'
to the issue so I know on exactly what windows version you are, maybe I can tried to reproduce the issue. however that said, re-ordering filters was mainly added for aesthetic proposes, to allow you to put filters that serve a certain purpose together and rarely affects their behaviour.
insert key: currently if you want to add a new filter you just click on the next line, what would the insert key improve apon this? it is about not using the mouse?
the width of the Filter column: I think what you describe is (or should be) the current behaviour. see screenshot below
the size of the filter dialog: I can see the use for this, I have created a separate issue #289 for it
copy/paste filter lines: will I see you point, but filters are rarely exactly the same, and you can already copy/paste the filter-text, so when it that really useful, could you describe your usecase?
Caption OSArchitecture Version Microsoft Windows 10 Home 64-bit 10.0.15063
Hmmm. Possibly I am not running the most recent build. I get 1.2.0.4 May 23, 2014 from the About box.
drag and drop re-ordering: already possible, just drag the filter by its name and drop it anywhere, maybe it is not working for you? in that case, please add the result of run 'wmic os get Version, Caption, OSArchitecture' to the issue so I know on exactly what windows version you are, maybe I can tried to reproduce the issue. however that said, re-ordering filters was mainly added for aesthetic proposes, to allow you to put filters that serve a certain purpose together and rarely affects their behaviour.
My Filters dialog has "Log Filter Settings" as the caption, not "View/Filter Settings" and the text ", drag to rearrange" is missing.
Isn't the order of filter lines important? E.g. I have the following filter lines when debugging MyApp:
(shell|chrome|onecore) regexp exclude
(error|fatal) regexp highlight red background, yellow text
MyApp simple highlight light gray background, black text
If I place line 2 after line 3 I don't see the error lines at all.
insert key: currently if you want to add a new filter you just click on the next line, what would the insert key improve apon this? it is about not using the mouse?
That always appends a new line. My suggested behaviour would be:
A new filter line would appear after line 2 and line 3 would be shifted down. I realise - assuming I am running an old build, and drag and drop is possible - that drag and drop makes this feature less relevant, as you would just need to add the new line at the bottom and drag it to the desired position.
the width of the Filter column: I think what you describe is (or should be) the current behaviour. see screenshot below
When I resize the dialog the Filter edit box doesn't resize.
the size of the filter dialog: I can see the use for this, I have created a separate issue #289 for it
Thank you.
copy/paste filter lines: will I see you point, but filters are rarely exactly the same, and you can already copy/paste the filter-text, so when it that really useful, could you describe your usecase?
Granted, copy and pasting the Filter text is helpful, but it is always useful when creating new filter lines to start with one that largely does what you want. Copy and paste would be especially useful for the background and foreground settings. As an example, if I already had:
(error|fatal) regexp highlight red background, yellow text
and I wanted to similarly highlight the lines with OK or PASS in them, I could:
(error|fatal) regexp highlight red background, yellow text
(OK|pass) regexp highlight green background, yellow text
(didn't mean to close it!)
v1.2 is very old please make sure to try v1.8 that was released this week.
The latest version can always be found here:
In the filter example you give the order should not matter, if it does, I think it is a bug. However, in v1.2 the filtering behaviour might have been different, so please try v1.8 for that too.
In the copy/paste example for the filter, the only re-use of the filter is the yellow foreground color. So it does not make much difference if you copy/paste the filter or select the foreground color. I do think it is worth the extra effort, sorry :) One more option: if you really have to do a lot of filter-editing, you can also save the filters as xml and bulk-edit them in your favorite editor.
OK, I got 1.8 and installed it. Yes, the filter lines can be re-ordered by dragging, and the dialog resizes the controls sensibly. Well done.
As regards the way the filter lines are interpreted, my impression is that the order definitely matters. I wouldn't go so far as to call it a bug - the way it works seems quite intuitive, especially the fact the highlight rules processed from the top and the first one to match wins.
I had it crash when I tried to load an ASCII debug log from another program. I'll report it when I have characterized it a bit better.
Actually, I'm pretty impressed by the whole thing. The impact on the program being debugged is minimal, even if I work it really hard.
Thank you, yes, I have optimized it specifically to minimize the delays, this is my test scenario:
D:\project\DebugViewPP\Release>DbgMsgSrc.exe -1 DbgMsgSrc, pid: 7144 Reading titan_crash_debugview_43mb.log... writing... 167030 lines OutputDebugStringA 167030 lines, took: 3425 ms
D:\project\DebugViewPP\Release>DbgMsgSrc.exe -1 DbgMsgSrc, pid: 8020 Reading titan_crash_debugview_43mb.log... writing... 167030 lines OutputDebugStringA 167030 lines, took: 1081 ms
from that I deduce that I introduce about ~15us per line, which is the best I have been able to get :)
Compared to dbgview from sysinternals, that is about a factor of 20! better ...
D:\project\DebugViewPP\Release>DbgMsgSrc.exe -1 DbgMsgSrc, pid: 7120 Reading titan_crash_debugview_43mb.log... writing... 167030 lines OutputDebugStringA 167030 lines, took: 50819 ms
I'm looking forward to you crash scenario, if you can, please send me a crashdump. You can create by adding the attached .reg file to your registry, a crash dump file will be created in c:\crashdumps
closing this issue, for clarity, RrnR, please open a new issue if you're still missing something.
I can find no way to change the order of lines in the filters dialog. I'm assuming that the filters are processed in order - i.e. the order in which you enter filters is significant.
There are several related enhancements the filters dialog would benefit from:
Most of these could be accessed from a right-mouse menu containing: