janwilmans
commented
6 years ago this is very interesting, I've been wanting to add this myself. I'm happy to collaborate, the way I envision this, is but doing a plugin like #191 Also the subject of coloring has been requested before, #208 is related.
The way this would work is that a plugin is a .dll in a plugins/ sub-directory that is loaded if it is found. The way I see this, we would search the plugins/ directory if the 'plugins' dialog (to be created) is opened. The binary interface of the plugin we would need to design.
- would it get all incoming text or only included lines?
- how would we communicate the desired formatting?
The drawing of lines is done in LogView.cpp in CLogView::DrawItem(CDCHandle dc, int iItem, unsigned /iItemState/) and it already pretty involved.
Let me know what you think
Many sophisticated codebases use ANSI terminal coloring in their debugging output, so that things errors may be red, warnings yellow, etc. And even more sophisticated schemes. Granted this applies to terminal/console output, however Microsoft introduced about a year ago, proper terminal/ANSI code handling for the command console.
When one finds (as I have) that we are modifying code bases to print debug output to debugview, it is a terrible shame to lose all the app-specific and inspired coloring. Granted, I can color whatever I like in Debugview++ but that is an enormous amount of work to recreate and also DBV++ does not have enough information to make determination of color. Only the app knows the right coloring for a given piece of output.
The feature which would be great would simply look for ANSI escape codes in the outputstring, and interpret the color commands and 1) print the text following the commands in that color until a RESET ansi code is seen and 2) NOT print the raw escape codes.
I have the code base to process and interpret ANSI codes, but I don't know DBV++ well enough to know where and how that might go. If you want to collaborate on this, I can make the change.