Enhanced Debug Console Output

[fafalone]

Since the debug console already supports color, users being able to access the color as a property would aid in debugging by making it easier to see which particular line is currently important.

This can be accomplished with a .TextColor property in the Debug object.

Sub PrintCritical(sMsg As String)
Debug.TextColor = &HFF0000
Debug.Print sMsg
Debug.TextColor = vbDebugColorDefault ' (have a constant for the default color)
End Sub

Another useful feature would be a .PrintEx method that would take the color as an argument, as well as a Level argument.

Debug.PrintEx(message As String[, Level As tbLogLevels, Color As Long])

Then in project settings a corresponding setting of the minimum level to show. A helpful default enum,

Enum tbLogLevels
    LogInformation = 0
    LogMedium = 1000
    LogCritical = 2000
End Enum

the gaps would allow room for custom user levels.

[Kr00l]

Debug.Print allows , to be used as tabbed output.
Wouldn't this conflict in syntax with your proposed PrintEx? Or am I overlooking something?

Why not having just a Debug.Level property ? I know it's not so handy as in-line but looks quite VB-ish whatsoever.

Also, just as a discussion, the Debug.TextColor could be shortened to just Debug.Color ? There will never be another color (e.g. background) possible?

[WaynePhillipsEA]

I'm not sure Level is the right word. Perhaps Severity?

I suppose we could allow for changing the back color as well whilst we're at it?

[fafalone]

PrintEx isn't meant to have tabbed output as it needs to have more than one argument.

You could have a separate Level property but it seems like it would need to be changed so frequently as to be really painful; plus the color argument is still needed.

Future color options would include BackColor and TextBackColor.

I had went with levels over 'Severity' as IMO Severity implies it's an error; though I suppose other IDEs/languages so consider 'information' as a severity degree of error.

[WaynePhillipsEA]

Or do we instead offer multiple DEBUG CONSOLE output panes for each level/severity:

Debug.Print ' normal
Debug(CRITICAL).Print ' outputs to a separate console

Or;

Debug.Print ' normal
Debug.Critical.Print ' outputs to a separate console

Just floating ideas.

[fafalone]

I like the idea of multiple windows, but perhaps it would work better from the other side; allow the IDE to open multiple debug consoles, and each one would have an option for the range of levels it shows. (And an additional option for IDE/compiler-originated messages, vs user debug output??)

[WaynePhillipsEA]

Yes, that could work. Makes it much more flexible. We could still use the print syntax Debug.Critical.Print etc, if that is preferred over setting a property.

[fafalone]

For me it's been useful to not just have a few fixed levels but be able to specify any number; particularly when working with large projects needing a lot of output; that's why I used 0/1000/2000 as baselines instead of 0/1/2.

[Kr00l]

Debug.Print(1000, vbRed) ...

Would that be possible to allow optional arguments on the Print itself?

And btw. Indent could also be a possibility over Level ? Because that would tell what it actually is ?

[WaynePhillipsEA]

For me it's been useful to not just have a few fixed levels but be able to specify any number; particularly when working with large projects needing a lot of output; that's why I used 0/1000/2000 as baselines instead of 0/1/2.

This would make the UI filtering per console more difficult. Rather than having a few simple presets we then have to allow for filtering by number. Not impossible, but just makes things more complex than it perhaps needs to be.

[fafalone]

All you'd need is 2 additional textboxes instead of 1... or just one that allows a range like 100-200.

[WaynePhillipsEA]

We need more eyes on this.

[Kr00l]

We need more eyes on this.

Agree. I would not rush something and then regret it at is is sub-optimal and you need to stick/support it. This especially comes after v1 as every break is sensitive and requires big announcement.

[bclothier]

I want to point out that if you look at more modern solutions, they have placed more emphasis on things like:

1. Not assuming what is the output -- if it's a headless automation, debug.print going to a console is not helpful; it should be redirected to stdout? stderr? . Ditto with using files (which we do via TracePrint).
2. More emphasis on envelopes -- they might now prefer using JSON as the output, rather than just human readable text. This is helpful when wiring it up for automation, or for feeding to AI agents as it guarantees that the data is shaped in a consistent format and avoid complicated parsing which can be brittle.

Note that this has some cross cutting concerns that goes beyond the simple Debug.Print. I'd prefer that a logging library be a package but even such logging library would necessarily need to be able to "plug in" the Debug and thus collect its output. That way, the Debug object itself stays focused but allows for more extensibility because the output formats and the formatting shouldn't be its concern.

So if we assumed the LCD -- a monocolor terminal -- then passing colors doesn't make sense; there's nothing to color and it would give an appearance of being broken. However, if we specify Debug.Error / Debug.Warn / Debug.Print / Debug.TracePrint for Error / Warning / Print / TracePrint, respectively, then the monocolor terminal is free to accommodate the request (perhaps by generating a header), while the multicolored terminal is free to color the different severity, and the file is again, free to decorate it differently. Maybe they want it in .txt which means it's back to monocolor or maybe they want it in .rtf which supports some color, maybe JSON which means the severity is a property printed out in the JSON object... You see where this is going. My point is that the Debug object doesn't need to know those things because that is a output problem, and that's not Debug's problem.

Which circles back to the earlier point about extensibility -- tB IDE can ship a default DebugFormatter class that works with its own Debug console and handle it accordingly and expose it as an object that can be manipulated by either user's preferences or at runtime, or the user has the option of implementing their own DebugFormatter.