Implement drag and drop to reorder filter lines, and other related enhancements

[RrnR]

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:

• drag and drop re-ordering
• Insert key could insert a new filter line after the currently selected line.
• the width of the Filter column could respect the width of the dialog, i.e. when you resize the dialog the Filter column width should automatically adjust to use up the width remaining.
• the size of the filter dialog should be remembered - certainly during a session (if I open the dialog, adjust the size of the dialog, close the dialog, then open it again, the width and height are reset to the designed dimensions) - and ideally between invocations of DebugView++.
• copy and paste of filter lines

Most of these could be accessed from a right-mouse menu containing:

• Insert
• Copy
• Cut
• Paste
• Move up
• Move down (Move up/down would be easier to implement than drag and drop)

[janwilmans]

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?

[RrnR]

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   

• The first line gets rid of the chaff from debug output of other applications.
• The next one makes sure that error output lines of MyApp get through and are highlighted.
• Line 3 shades the output from MyApp and makes it easier to spot foreign output in the stream.

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:

• click on line 2 (say) to select it. It would have to be a position on the line that wasn't in the "Filter" edit box.
• Press the Ins key (or right-mouse/Insert)

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:

• right-click the line and select Copy
• right-click below the line and select Paste
• Edit the text to change "error|fatal" to "OK|pass"
• Click on the foreground colour and select green.

(error|fatal)          regexp   highlight    red background, yellow text
(OK|pass)              regexp   highlight    green background, yellow text 

[RrnR]

(didn't mean to close it!)

[janwilmans]

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:

https://github.com/djeedjay/DebugViewPP/releases

[janwilmans]

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.

[RrnR]

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.

[janwilmans]

Thank you, yes, I have optimized it specifically to minimize the delays, this is my test scenario:

first test writing 167030 lines with debugview++ open:

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

now test without debugview++:

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

configure_crashdumps.zip

[janwilmans]

closing this issue, for clarity, RrnR, please open a new issue if you're still missing something.