The console writer assumes the background color is black

[jpluimers]

When setting colors, the console writer assumes the background colour is black.

But on most of my systems it is white, resulting in very hard to read output.

The console writer should either force a black background, or (much harder) choose the foreground colours to contrast nicely with the background colour.

[vincentparrett]

Is there a way to get the default console colour on startup? If so then we could use that to determine the correct colors to use.

[LarsFosdal]

To get the current console color, use WinApi.Windows
function GetConsoleScreenBufferInfo(hConsoleOutput: THandle;
var lpConsoleScreenBufferInfo: TConsoleScreenBufferInfo): BOOL; stdcall;

The TConsoleScreenBufferInfo structure is documented here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682093(v=vs.85).aspx

The wAttributes field contains the color info - but it is a tad archaic ...
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682088(v=vs.85).aspx#_win32_character_attributes
Basically it's an R, G, B and an intensity bit for background, and ditto for foreground.

Since console windows don't have more than 16 possible foreground and background colors, it's an option to create a static list of 4-5 foreground colors that give good contrast for each of the 16 background colors.

[rmcginty]

It could be more complicated because the background color can be anything:

http://www.howtogeek.com/howto/16815/how-to-personalize-the-windows-command-prompt/

I wasn't aware it could even be changed without a hack, so documenting link here.

I have a couple of ideas, but I'll have to experiment first...

[jpluimers]

More info: http://stackoverflow.com/questions/9509278/rgb-specific-console-text-color-c/9509664#9509664

Basically the colours are indexes into the colour table. The colour table can then have RGB values for each entry.

For now it would suffice to cope with the standard RGB values, as I've not yet seen people change those RGB values in practice.

[rmcginty]

As a quick fix, change TDUnitXConsoleLogger.SetConsoleDefaultColor() in DUnitX.Loggers.Console from:

FConsoleWriter.SetColour(ccDefault);

to:

FConsoleWriter.SetColour(ccWhite, ccBlack);

The other "SetColour" commands all explicitly specify black for the background, so setting the default to while on black makes the output look correct no matter the background color of the console. I tried it out and it works great.

[rmcginty]

I thought I had already made this change in my local version, but apparently I didn't (or I accidentally merged it back in). Has anyone used the change in enough of a capacity to say it is a safe change to make permanently? I know in my testing it worked fine, but wanted more feedback if it was available.

[jpluimers]

@rmcginty if you have a patch, let me know where the repo with that patch is and I'll test it. All my console Windows are black text on a white background.

[rmcginty]

I already have an active PR and I really do not want to try a branch since I just got my GitHub repo all back to normal, but it literally is the single line change. Open DUnitX.Loggers.Console.pas and change line 447 to:

FConsoleWriter.SetColour(ccWhite, ccBlack);

That will keep it from resetting to the default colors, which is what keeps resetting your background to white. Honestly, if the system isn't going to detect background color and compensate (which is a bunch of work for little gain - especially using tools available on the console) then it should really just force a specific color scheme regardless of your default colors - just to keep it standard and readable.

If you notice no unintended side effects from this change, let me know and I'll clean up the file some, make the change, and attach it to my existing PR.