Can I disable procedure 'DebugLn', which is called by the LCL, in my program?

[Hartmut]

My program works, but it writes on the console a certain debug message (a warning coming from the LCL via procedure 'DebugLn') very often. I want to get rid of this messages, they deface my console output.

Is there e.g. some kind of Flag, which I could set to 'disable' so that procedure 'DebugLn' does not show its output any longer? Or is there another way?

I use Lazarus 2.0.10 with FPC 3.2.0. Have the same debug messages with Lazarus 2.2.4 / FPC 3.2.2. Thanks in advance.

[Martin_fr]

Try using "uses LazLoggerDummy" in one of your units. Unless you use debugln yourself, then you are out of luck, it's all on, or all off.


IMHO those LCL debugln should probably be put into IFDEF.

[Hartmut]

Thank you Martin_fr for your suggestion. Unfortunately it does not work. I still get those debug messages.

I added 'LazLoggerDummy' to my uses-list. I do not call anything from this unit. I do not use 'DebugLn' at all. Was this correct?
I use Lazarus 2.0.10 with FPC 3.2.0. Same result with Lazarus 2.2.4 / FPC 3.2.2. I'm on Linux Ubuntu 22.04 (if that matters). Thanks for your help.

[Martin_fr]

Then the LCL probably forces the LazLogger. Meaning it must be changed in the LCL.

IMHO => report as bug.

[Hartmut]

As I wrote in my 1st post, the call to 'DebugLn' comes from inside the LCL:

Code: Pascal  [Select][+][-]

1. // line 6411 of /.../lazarus/lcl/interfaces/gtk2/gtk2winapi.inc
2.  
3.     if (LCLObject=CurrentSentPaintMessageTarget) then
4.     begin
5.       DebugLn('WARNING: TGtk2WidgetSet.InvalidateRect refused invalidating during paint message: ',
6.         LCLObject.ClassName);
7.       exit(False);
8.     end;

I don't want to edit my LCL for a couple of reasons. My question is: is there another way to disable the output from above procedure 'DebugLn' by my own program?

[JuhaManninen]

I don't want to edit my LCL for a couple of reasons. My question is: is there another way to disable the output from above procedure 'DebugLn' by my own program?

Not really.
I guess Martin means that LCL somewhere uses "LazLogger" while it shoulld use only "LazLoggerBase" everywhere.
You should also try the new fixes_3_0 branch. Lazarus 3.0 is not released yet but you can build it from sources easily. Then the sources are in a writable directory and commenting out any unwanted DebugLn is easy.

[Martin_fr]

debugln is activated, if anything in your app (any of your units, or any unit of any package... just any ONE unit) uses the unit "LazLogger".

Most units that have the debugln statement, use the unit "LazLoggerBase" which will
- look if the unit LazLogger was used (or if anything else instantiated a logger
- then either log or ignore.

You can look at the unit LazLogger.

And the change properties on the global "DebugLogger". 
Maybe

Code: Pascal  [Select][+][-]

1. uses LazLogger, LazLoggerBase;
2. LazLogger.DebuggLogger := TLazLoggerNoOutput.Create;

I found that the lcl had one "uses LazLogger" in "unit WSMenus;" => I replaced that by LazLoggerBase.

Also changed the 3.0 fixes branch, so hopefully this will silent that.

[Hartmut]

Thanks JuhaManninen for your reply. Switching my program to another Lazarus version now is not an option.


Thank you very much Martin_fr for that solution.

Code: Pascal  [Select][+][-]

1. LazLogger.DebugLogger:=TLazLoggerNoOutput.Create;

did not compile (Error: Incompatible type for arg no. 1: Got "TLazLoggerNoOutput", expected "TLazLoggerFile"), but this line does compile and works perfectly:

Code: Pascal  [Select][+][-]

1. LazLoggerBase.DebugLogger:=TLazLoggerNoOutput.Create;

Meanwhile I found another "solution" by playing with the interface variables of Unit 'LazLoggerBase':

Code: Pascal  [Select][+][-]

1. LazLoggerBase.LazDebugLoggerCreator:=nil;

The advantage of this way is, that I can save & restore it's value, so that only my known command, which produces the debug warning, runs with 'DebugLn' disabled and I could see other warnings, if any would occur some day.

My question is now: how "dirty" is my method? Are there reasons, not to do so?