Suppressing LCL debug messages

[MarkMLl]

I habitually build FPC with minimal optimisation and maximum debug info, and then use this to build Lazarus using "make bigide". Both of these are actually wrapped in shell scripts, in particular to ensure that Lazarus is built with currently-loaded packages such as LazMapViewer.

When I run a program, the LCL is inclined to spit debugging warnings at me such as

Code: Text  [Select][+][-]

1. $ ./dsocat-x86_64-linux-gtk2
2. WARNING: TGtk2WidgetSet.RegroupMenuItem: handle is not a GTK_RADIO_MENU_ITEM
3. WARNING: TGtk2WidgetSet.RegroupMenuItem: handle is not a GTK_RADIO_MENU_ITEM
4. WARNING: TGtk2WidgetSet.RegroupMenuItem: handle is not a GTK_RADIO_MENU_ITEM
5. WARNING: TGtk2WidgetSet.RegroupMenuItem: handle is not a GTK_RADIO_MENU_ITEM
6. $
7.  

I can see that these are being emitted by DebugLn(), in this particular case in gtk2winapi.inc

Can the IDE and LCL be built in a way that suppresses these messages, without compromising debuggability?

Looking at the makefile etc., it appears that DEBUG controls both DebugLn() (in multiple source units) and -gl on the compiler command line: is there a safe way to split this e.g. would the Lazarus build process honour something like OPT='-gl'?

MarkMLl

[Martin_fr]

debugln is handled entirely independent of -g -gl and other compiler switches. Unless there is somewhere (of which I would not be aware) some {$IFOPT debug??? } .

debugln should go through LazLogger (but there may be some old stuff still going to LCL).
LazLogger can be controlled by NOT using the unit LazLogger.

debugln should go to LazLoggerBase (or LazLoggerDummy).

LazLoggerBase will only be activated, if any unit in the app uses actually LazLogger.

Then you can still control the global Logger instance....

[MarkMLl]

debugln is handled entirely independent of -g -gl and other compiler switches. Unless there is somewhere (of which I would not be aware) some {$IFOPT debug??? } .

debugln should go through LazLogger (but there may be some old stuff still going to LCL).
LazLogger can be controlled by NOT using the unit LazLogger.

debugln should go to LazLoggerBase (or LazLoggerDummy).

LazLoggerBase will only be activated, if any unit in the app uses actually LazLogger.

Then you can still control the global Logger instance....

OK, but it appears to be pulled unconditionally into (at least) the GTK2 widget set interface.

Can I inhibit it at runtime by assigning to these

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

1. ...
2. // Using base TRefCountedObject, so if none of the functions is used in the app, then even the class should be smart linked
3. var
4.   LazDebugLoggerCreator: TLazDebugLoggerCreator = nil;
5.   OnWidgetSetDebugLn: TLazLoggerWidgetSetWriteEvent;
6.   OnWidgetSetDbgOut:  TLazLoggerWidgetSetWriteEvent;
7. ...
8.  

MarkMLl

[Martin_fr]

I would have to look through the code when and how to use those events.

You can use the unit LazLogger, and the IIRC DebugLogger  has events that can be hooked.

If you can get the creator hook to go to your code (and not later be set by other units), then you can create a dummy logger object.

The IDE does pull in the unit LazLogger. And it should.

I don't know if/where LazBuild does. But if it does, it may still be intention.

Component Code outside the ide folder should not do that. If it does, it probably should be reported.


Otherwise, there hasn't yet been any effort to unify how that kind of logging is controlled....

[MarkMLl]

I can trap the write in TLazLoggerFileHandle.WriteLnToFile() but it's one of those irritating situations where doing so locks up the UI (because it's a menu event handler)... I still get a good callstack window which shows it's coming from TGtk2WidgetSet.RegroupMenuItem() (which is where I got to when grepping for the message) via TLazLoggerFile.DoDebugLn()... ...

OK,

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

1. LazDebugLoggerCreator := nil;
2.  

after the message loop etc. has been initialised at some convenient point early in the program appears to shut it up.

This is specifically GTK2, and- and my apologies for not mentioning this right at the beginning of the thread- Lazarus 2.2.6.

MarkMLl

[Martin_fr]

I can trap the write in TLazLoggerFileHandle.WriteLnToFile() but it's one of those irritating situations where doing so locks up the UI (because it's a menu event handler)...

Not sure if I follow. Not sure how the logger should lock up the app, if it immediately returns to the app and lets the app continue?

If you set breakpoints there, and trap this in the debugger => start the IDE and your app with  --sync
Actually, I don't know, maybe its just one of the two that needs it...
For the IDE, start it from a terminal with --sync  and for the app in the debugger you can specify it in run parameters.


About gtk2:
My answers are limited to the LazLogger site. And even there, I don't have all details memorized...

As for what the LCL-WS code logs, and how it does that, I can't comment on.
Also I don't know if all those messages come from the LCL / LCL-WS code. Or if gtk itself may emit warnings under some conditions.

[MarkMLl]

I can trap the write in TLazLoggerFileHandle.WriteLnToFile() but it's one of those irritating situations where doing so locks up the UI (because it's a menu event handler)...

Not sure if I follow. Not sure how the logger should lock up the app, if it immediately returns to the app and lets the app continue?

This isn't a logger problem, I suspect it's GTK2+KDE: set a breakpoint in a (menu) event handler and more often than not the screen locks up until the program being tested is killed from a non-GUI session.

MarkMLl

[Martin_fr]

This isn't a logger problem, I suspect it's GTK2+KDE: set a breakpoint in a (menu) event handler and more often than not the screen locks up until the program being tested is killed from a non-GUI session.

--sync

At least on some distros that helps.

[MarkMLl]

This isn't a logger problem, I suspect it's GTK2+KDE: set a breakpoint in a (menu) event handler and more often than not the screen locks up until the program being tested is killed from a non-GUI session.

--sync

At least on some distros that helps.

Thanks, I'll check when next looking at something like this and report back.

MarkMLl