Forum > Debugger
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 [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---$ ./dsocat-x86_64-linux-gtk2WARNING: TGtk2WidgetSet.RegroupMenuItem: handle is not a GTK_RADIO_MENU_ITEMWARNING: TGtk2WidgetSet.RegroupMenuItem: handle is not a GTK_RADIO_MENU_ITEMWARNING: TGtk2WidgetSet.RegroupMenuItem: handle is not a GTK_RADIO_MENU_ITEMWARNING: TGtk2WidgetSet.RegroupMenuItem: handle is not a GTK_RADIO_MENU_ITEM$
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:
--- Quote from: Martin_fr on January 10, 2025, 02:30:05 pm ---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....
--- End quote ---
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 [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---...// Using base TRefCountedObject, so if none of the functions is used in the app, then even the class should be smart linkedvar LazDebugLoggerCreator: TLazDebugLoggerCreator = nil; OnWidgetSetDebugLn: TLazLoggerWidgetSetWriteEvent; OnWidgetSetDbgOut: TLazLoggerWidgetSetWriteEvent;...
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 [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---LazDebugLoggerCreator := nil;
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
Navigation
[0] Message Index
[#] Next page