Debugging run doesn't get to .PAS file ?? lazarus / 12-Debugger ---------------------------------------------------------------------- J-G · 2022-01-12 14:06 I haven't needed assistance for quite some time - essentially because I haven't been writing any code!! Having been annoyed at seeing one of the programs I use daily show that a 'Next date' should be '209th Dec'  and wanting to sort out why, I did some small adjustments yesterday to display what dates were actually being calculated. I'm well aware of how to set 'Debugging' and stepping through code with f7, f8 etc. and how to set breakpoints but - out of the blue - the form is partially created (and displayed) before breakpoints in the .pas file are activated. I've set breaks in the .LPR file and they are obeyed but as soon as I expect to see a transfer to the .PAS file part of the form is created but the breakpoints in 'FormCreate' are ignored  -  and the form isn't correctly displayed. Here is the 'FormCreate' code. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i procedure TForm1.FormCreate(Sender: TObject);begin  Top    := 200;  Height := 300;  Width  := 860;  Left   := (Screen.width - width) div 2;  Left := Left + Screen.Width;                     // move to screen 2   ReadDate;   ConfigDir := GetAppConfigDir(OK);  Read_Path;  CreateBlankRecords;   CaptionLabels(DataYear);   AssignFileNames; //  Read_History;   Calc_Meter_Read_Dates;      // 585       (Breakpoint set here)   CreateOrRead_Files;         // 1943 //  Correct_Errors;   ShowGasFactors;  Saved := FiT_Data[YearIndex,DayIndex].Value > 0;  CheckIfReadingDue(DayIndex); //  ReadCSVFile;   ShowRecord(YearIndex,DayIndex); end;  I have checked that other programs do debug correctly using the same Laz installation which has served me very well for many years.  (ver 1.6) ---------------------------------------------------------------------- Martin_fr · 2022-01-12 14:45 "Laz 1.6" => so presumingly we are talking about the "gdb based" debugger. (not FpDebug). Not sure how long you've been on Fpc 3.0 ? 1) There are known issues with line info generation (and they might be older, i.e. present in 3.0.0). If you have "dead code" above the function... If in front of "TForm1.FormCreate" is another function, and if that function is never called (and therefore not included in the exe / no blue dots at all). Though the expected issues do not match exactly your problem, check if it is the case. 2) Breakpoints (in gdb based debugging) are set, somewhere in the start up code of your app. Unfortunately, after the unit "initializations" sections have run. If you create your form, from within an "initializations" section, then the breakpoints are not yet set (that has always been like this). Btw: appearing of the "blue dots", and setting of breakpoints, can be at different times. I have no idea what features were avail in 1.6. Check in Tools > Options > debugger options (the property grid) for "InternalStartBreak" and try to change it. May have an effect.... 3) Could be changes to Windows.... You can try other versions of gdb (downloads on our Sourceforge page for 64 and 32 Win). Not sure which one work, within an old 1.6. I would expect up to, and including gdb 7.* / Maybe gdb 8.*  (gdb 9.* and up, will most likely need a newer Lazarus) ---------------------------------------------------------------------- J-G · 2022-01-12 16:16 Thanks for your input Martin - I'm not sure it will help I've been using 1.6 since I first discovered FP & Lazarus - I think in August 2016 - but that’s only taken from my Laz folder date - it could have been prior, and of course it will be GDB based but I only know that by looking at the IDE options which I can’t recall ever doing previously.  What I’m saying here is that Laz & FP ‘just works’ for me and I haven’t ever needed to do more that switch the debugger on or off as needed, all settings are ‘out of the box’ as it were. As far as I am aware there is no “dead code” and I don’t have an issue with ‘Line Info generation’  - yesterday this code compiled and ran, just as the many other programs I’ve written - it simply records and displays meter-readings in graph-form and has done since 2014 (This may mean that I’ve been using FP & Laz prior to 2016 !!) I've just added a panel with some TLabels to display numbers indicating Day of Year. Here is the code in the .LPR file - in fact the whole .LPR file : Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program Energy; {$mode objfpc}{$H+} uses  {$IFDEF UNIX}{$IFDEF UseCThreads}  cthreads,  {$ENDIF}{$ENDIF}  Interfaces, // this includes the LCL widgetset  Forms, datetimectrls, tachartlazaruspkg, PowerUse  { you can add units after this }; {$R *.res} begin  RequireDerivedFormResource:=True;  Application.Initialize;  Application.CreateForm(TForm1, Form1);  Application.Run;end.  I set breakpoints by ‘clicking’ within the margin of the IDE which sets that line to [ RED ]. In the Tools > Options > debugger section (I haven’t previously even looked at that section) there are 4 sub-categories : General; Event Log; Language Exceptions; OS Exceptions. No settings within any section has been changed - as far as I know.   Just in case I have done something silly by accident, This is the debugger path ‘$(LazarusDir)\mingw\$(TargetCPU)-$(TargetOS)\bin\gdb.exe’  My LazarusDir is T:\Lazarus wherein I have 3 ‘gdb.exe’ files : [mingw\i386-win32\bin (3/12/15)] - [mingw\x86_64-win64\bin   (27/9/11)] & [fpc\3.0.0\bin\x86_64-win64   (14/2/16)] There is no additional search path, ‘Show message on stop’ is ticked but ‘Reset Debugger after each run’ is not.    "InternalStartBreak" is set at [gdsbDefault] and has not been changed  - there are 4 other options :  gdsbAddZero  -  gdsbEntry  -  gdsbMain   -   gdsbMainAddr   but since I have no idea what each option does would appreciate guidance. I do not allow any changes to ‘Windows’ - I’m still using Win 7 Ultimate 64 (on this PC) and don’t allow updates of any kind. The fact that other programs compile and run perfectly as they did previously and that just this one program exhibits the fault seems to indicate that I have inadvertently clicked on some setting or deleted some code - both sound implausible ---------------------------------------------------------------------- Martin_fr · 2022-01-12 16:38 Well yes, I have on issues with you using whichever version you want... But also, I am not going to go back and check what option 1.6 had, or what bugs.... You can try gdsbAddZero   for InternalStartBreak. But I am not sure it will help. (especially, if you do stop in the LPR / and if you do not have code in "initialization" that triggers your form create) I can't thing of any option that would match your description: QuoteI've set breaks in the .LPR file and they are obeyed but as soon as I expect to see a transfer to the .PAS file part of the form is created but the breakpoints in 'FormCreate' are ignored  -  and the form isn't correctly displayed. ".pas" being the unit with the form? You could try switching between debug info => stabs or dwarf You could try disabling "external debug info" (if you use it). It should not cause issues, but... well clutching at straws. I assume the form is part of the project (not in some package?) => so it is compiled with debug info? (if on Windows) You could try -Xe (external linker). Just in case, fpc gets upset by something.... again clutching at straws. Then the question is => is the event OnFormCreate even called? Is it still set in the lfm? And is it correctly loaded by TReader from the lfm? Is OnFormCreate  stil published? (not public, but published)? Is there an exception before it is entered? Just throwing in anything I can thing of, however unlikely.... ---------------------------------------------------------------------- J-G · 2022-01-12 18:02 Totally understand your position Martin and appreciate that you can only 'clutch at straws'. FP 3.0 & Lazarus 1.6 have always simply worked for me and I'm not creating commercial applications - I don't really use OOP - I still prefer 'old style' at my age There has been a further development inasmuch as when I press [f9] I no longer see 'messages' ??   The [Message] Window appears but there are none ??  I then noticed that the Object Inspector is blank !!  and I can no longer see the form  D'oh!  -  don't know how but the .LFM file had been deleted - thank the 'Lazarus Gods' that they create a backup!!  Form and messages now returned. I have tried changing the settings for 'InternalStartBreak' but without any effect. As you'll see from the 'FormCreate' code, the first thing that I do there is to set the position, height and width. This is because I normally only want to show the top section. What happens now is that the outline of the whole form (887 wide x 785 high) is shown along with the three charts (empty), a few of the labels, edits and panels (not all). This seems to me to show that for whatever reason the [form] is not being correctly included in the 'compile'. I don't do anything extra-ordinary as far as using 'external' facilities, the .LPR file is 'Energy.LPR', the main unit is 'SolarPower.PAS' and the Form is SolarPower.LFM.  I just use [f9] to compile the project.   Is there some other means by which I can 'force' a complete [build] should there be some component that is being ignored? All I've added to the program since it last 'worked', is a check that 'Today's' reading is greater than 'Yesterday's' reading (along with a warning flag) and a panel to show which day of the year readings are needed by the energy supplier. What I have found is that I CAN get a breakpoint to trigger in another part of the program when I try to advance the period displayed. This shows that the debugger is operational - just not where the program starts - so it does seem that the FormCreate proc is not being included in the compile  How do I check if TReader is loading the Form?   (do I even understand what that means?) ... or that OnFormCreate is 'published'? There are no 'Exceptions' raised. ---------------------------------------------------------------------- Martin_fr · 2022-01-12 18:56 Quoteso it does seem that the FormCreate proc is not being included in the compileIf it is published => it will be included. But may not be called, if there is an issue with the lfm. I don't recall how lfm worked back then.... But: - You will have the original LFM, in the same dir as your pas file. - Make sure, that the names in the file, much the name in your pas file. - Make sure the OnFormCreate event has the name of your Form1FormCreate procedure (whatever it is exactly called). Then it depends..... The lfm may - be compiled into resources some *.res file.  => back them up, and remove all existing - or end up as a copy in your lib/unit folder (with the ppu files). Ensure there are no old lfm in any such folder. - or maybe back then be compiled into some "include" file (was it *.lrs ?)  => if there is such a file, move it away, and see if it is re-created. Also ensure it is actually included, into your app (not sure how to best test that / that is a long time ago, I last dealt with that). The lfr contains code, that creates a resource at runtime. ---------------------------------------------------------------------- J-G · 2022-01-13 00:17 Again Martin - excellent input which has given me the knowledge to find the location of the supporting/created files. At least I can now see exactly what files have been created and where. Regrettably, I don’t think I’m any further forward since the files I expect to see are all there and created at the same time (I was hoping to see at least one old file ) I can confirm that the .lfm compiles to a .RES file but there are also .LPI, .LPS & .LPR variants but no .LFR.  The file names also match as expected, as do the Proc titles. Tomorrow I’ll try backing up and emptying the folders to see whether that has any benefit. ---------------------------------------------------------------------- Martin_fr · 2022-01-13 00:41 Well, if the code is not called and that seems to be the case... 1) check (breakpoint) if TForm.Loaded is called. 2) In 2.2, but hopefully similar for you Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i TCustomForm.CreateNewcalls TCustomForm.ProcessResource;calls InitResourceComponent(Self, TForm)  // function in unit LResourcescalls InitLazResourceComponent and that (in a nested proc) Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i     LazResource := LazarusResources.Find(ResName);    if (LazResource <> nil) and (LazResource.Value <> '') then      Stream := TLazarusResourceStream.CreateFromHandle(LazResource); OR Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i       FPResource := FindResourceLFM(ResName);      if FPResource <> 0 then      Stream := TLazarusResourceStream.CreateFromHandle(HInstance, FPResource);  The first is the old *.lrs file The 2nd is for the .res So is that stream loaded? Further down Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Reader.ReadRootComponent(Instance);Is that called? (Instance => your form) I don't know if reader bails on every error.... The above stream, must contain the lfm ( I think,.... iirc at some time that is translated to bin...) Well and when that is done, the OnFormShom property/field should be set. Is it? And if you take the address ( TMethod(FOnFormShom).Code ) and paste that into the asm window's address => should be you event. But that is going way to far down.... should not be that deep... Btw, somewhere should be a setting to either use lrs or res... Maybe toggling that (and even toggling it back) ..... Project options > Miscellaneous > Resource type of project And your pas unit does it have {$R *.lfm} ---------------------------------------------------------------------- J-G · 2022-01-13 12:18 FOUND IT Not SOLVED - but I'm sure I've found the problem.  [ Edit ]  SOLVED I'm not ignoring your suggestions Martin  -  I don't (yet) understand what you are saying - but, having 'slept' on the issue I had a thought this morning to see if I could use an old version of the .LFM file. It would mean recreating the new panel etc. but at least I would hopefully be back to 'normal'. It so happens that I had a 2017 version compiled for x86_64-win64 rather than my current version i386-win32  -  I only know this due to your guidance Martin, they are both in the [Lib] folder.  Finding this led me to make copies of both .LFM files (64 & 32), re-name them as .TXT files so that I could view them in Notepad. Imagine my surprise to find this in the first few lines .... Current Version                                2017 Version object Form1: TForm1                     object Form1: TForm1   Left = 1532                                    Left = 174   Height = 785                                  Height = 789   Top = 117                                      Top = 100   Width = 887                                   Width = 860   Caption = 'Energy Costs'                  Caption = 'Energy Costs'   ClientHeight = 785                          ClientHeight = 789   ClientWidth = 887                           ClientWidth = 860   OnClick = FormClick                      OnCreate = FormCreate   LCLVersion = '1.6.0.4'                      LCLVersion = '1.6.0.4' It seems that somehow I've created an [OnClick] event and sure enough, on searching the IDE text there was an OnClick event declared and an 'empty' OnClick proc created. Easy to simply remove and let the IDE sort the bad declaration out. However, the current .LFM needs to be corrected. My simple approach was to correct it in Notepad, save the amended file then re-name the .TXT file back to .LFM. ..... well that didn't work     -   when I looked at the .LFM file again the 'OnCreate' line was missing altogether! I then accidentally double clicked on the 'LFM filename and (as you will already know!) it opened in the Laz IDE - so all my 'care' about editing was futile . Many 'adjustments' later I have been able to correct the 'OnClick' => 'OnCreate' debacle and am back with a working program !  I've also learned a great deal about the 'inner workings' of Lazarus  -  not that I anticipate that I will either need to know them or use them again, but I must again thank Martin  for his patience and willingness to dig deep into his historic knowledge to assist a numpty who was fumbling in the dark.