Ctrl-click is not working for some projects lazarus / 9-Editor ---------------------------------------------------------------------- RHollerich · 2023-06-28 17:51 When using the Lazarus IDE, I have a project with a few additional units. When I hover the mouse over a function call or variable, I can ctrl-click it and the editor will jump to the implementation of the selected function or variable regardless of whether the function/variable is in the same unit or some other unit. However, if I close that project and open a bigger project, I can only use ctrl-click to jump to variables declared in the function/procedure the mouse is in. Anything calls or variables defined/coded outside the function/procedure will not show any type of highlight and will not jump to the outside function/variable. I am assuming this must be a settings somewhere that tells the IDE to only jump to local variables, but I can not find anything like that in either Tools/Options or the project options. Any idea why one project allows jumping outside the function and another one does? Note: ctrl-click is set to "Jump to Implementation" in Tools/Options/Mouse. ---------------------------------------------------------------------- JuhaManninen · 2023-06-28 18:00 Does the project compile? Is the problematic unit part of the project? Codetools which parses the code is not perfect. For example some complex generics syntax can still confuse it. Still it works amazingly well in Lazarus project itself which is very big. Ideally it should work with any valid code, big or small. ---------------------------------------------------------------------- BrunoK · 2023-06-28 18:40 I have had, lately, the same problem. In ended that in a FPC unit that I had brought in the editor, intentionally or not, I  made an involuntarily change that ended in a syntax error that got save when compiling a Lazarus project. Restoring the damaged file re-enabled correct Ctrl-Click behavior. Do a Shift-Ctrl-Up where you expected Ctrl-Up to work and it may show a file in the messages window, or maybe, codetools even opens the damaged file. ---------------------------------------------------------------------- RHollerich · 2023-06-28 20:31 JuhaManninen - Yes, the project compiles and runs without any problems. In addition, it does not jump to anything outside of the function/procedure the cursor is in whether the thing I ctrl-clicked on is in the same file or another one. BrunoK - It could be a damaged file, but since it compiles and runs without any errors, I am not sure how to figure that out. As for Shift-ctrl-up, that takes me to the same file's interface section and puts the cursor on the name of the procedure/function where the cursor was before I did the key presses (note: it did not take me to the interface section of the function/cursor I had the cursor on but the function name that held the cursor). As for Crtl-Up, that is just causing the whole editor to scroll up one line at a time without changing the location of the cursor. for a simplified example of the problem, in the code below, if I do a crtl-click on the "s" in the line "s := 'Doing it';" the cursor will jump to the line "s:string;". However, if I do a ctrl-click on "DoThis" on the line "DoThis(s);" nothing happens. procedure Tform1.DoThis(value: string); begin //do something with value end; procedure Tform1.DoThat; var   s: string; begin     s := 'Doing it':     DoThis(s); end; ---------------------------------------------------------------------- dsiders · 2023-06-28 20:40 Quote from: RHollerich on June 28, 2023, 10:31:03 pmJuhaManninen - Yes, the project compiles and runs without any problems. In addition, it does not jump to anything outside of the function/procedure the cursor is in whether the thing I ctrl-clicked on is in the same file or another one. BrunoK - It could be a damaged file, but since it compiles and runs without any errors, I am not sure how to figure that out. As for Shift-ctrl-up, that takes me to the same file's interface section and puts the cursor on the name of the procedure/function where the cursor was before I did the key presses (note: it did not take me to the interface section of the function/cursor I had the cursor on but the function name that held the cursor). As for Crtl-Up, that is just causing the whole editor to scroll up one line at a time without changing the location of the cursor. for a simplified example of the problem, in the code below, if I do a crtl-click on the "s" in the line "s := 'Doing it';" the cursor will jump to the line "s:string;". However, if I do a ctrl-click on "DoThis" on the line "DoThis(s);" nothing happens. procedure Tform1.DoThis(value: string); begin //do something with value end; procedure Tform1.DoThat; var   s: string; begin     s := 'Doing it':     DoThis(s); end; I cannot reproduce this on WIndows using 2.2.4, 2.2.6, or trunk. ---------------------------------------------------------------------- Martin_fr · 2023-06-28 21:32 1) Does the error always happen? To explain, if you get the error (codetool does nothing) => save all files => restart the IDE => try ctrl-click on the exact same identifier => still nothing? 2) You said the error is only for idents that are declared in a different unit. That may mean there is a particular unit in the "uses" that blocks this. - Units are searched from the last unit (last in the uses clause) to the first. So if you get the error, then remove (comment out) units from the end of your uses clause, and retry. Is there a specific unit that can be commented to solve this? 3) What version of Lazarus are you using? It may be fixed in a newer version. => In the next few days the RC1 for the next version will be available. As soon as it is, test with that version. ---------------------------------------------------------------------- BrunoK · 2023-06-29 03:46 I have been able to reproduce what I was talking about. Modify "inadvertently" according to this description in your FPC 3.2.2. Around line 404 of your FPC\3.2.2-git\rtl\inc\systemh.inc file from the correct : 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   ALUUInt = QWord;to the incorrect 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   {A}LUUInt = QWord; {~bk}and save. Note : the marker is there so I can find where to undo the change. Now try to use ctrl-click. You can compile but no working Crl-Click anymore in the IDE. Dont forget to restore the correct code ! ---------------------------------------------------------------------- Eugene Loza · 2023-06-29 06:13 I've had this issue long ago. This was happening due to "something which was working fine in FPC confused CodeTools". In my case most often (always?) it was Generics.Collections unit including which literally crippled the ability of CodeTools to work properly (autocompletion, jump-to-definition, etc.). It's mostly fixed in current Trunk version of FPC/Lazarus. Now this bug only happens to me when FPC itself gets confused: but in this case the project won't build at all and the compiler dies with an "Internal Error" or related - until "build clean". ---------------------------------------------------------------------- Martin_fr · 2023-06-29 08:37 Quote from: BrunoK on June 29, 2023, 05:46:00 amModify "inadvertently" according to this description in your FPC 3.2.2. Around line 404 of your FPC\3.2.2-git\rtl\inc\systemh.inc file QuoteYou can compile but no working Crl-Click anymore in the IDE. Well, about "can compile" => the rtl is not compiled by the IDE. All the units are build already as ppu. You would need no build fpc (using make). On the other hand codetool gets an error somewhere, in some unit that uses "ALUUInt". After that codetool does not (and can not know) what is in the rest of the unit. (codetool stops on errror) So now if you look up "FooBar" and it isn't found (by order of scoping) before reaching the error post, the codetool stops. If codetool would continue in other units, it may show you the wrong identifier, since the correct one may be behind the error. ---------------------------------------------------------------------- BrunoK · 2023-06-29 10:06 Quote from: Martin_fr on June 29, 2023, 10:37:05 amWell, about "can compile" => the rtl is not compiled by the IDE except if I decide to do it. All the units are build already as ppu. You would need no build fpc (using make).Are you taking me for a beginner ? I know very well that nothing from the FPC directory is compiled with a Lazarus project, except if I want to do some units. I have enough versions of FPC, including some modified ones, to know how the build process functions. Rebuilding FPC takes me about 5 minutes when all goes well, an also sometimes much longer when I have managed to put a mess in my FPC install. CodeTools also reads the FPC source to find declarations when using Ctrl-Click and apparently stops if something is wrong in the FPC source syntax without any indication of what happened. Non working Ctrl-Click does not react, but as a matter of fact, at least in my installation, Ctrl-Shift-up did on occasions bring me to that error code line, but not always, and I did not figure out that a wrong source could hang walking thru the code without any warning (Empty message Window). Just try to introduce my involuntary mistake in the place I mention (probably other places in FPC source  would also do) and Ctrl-Click on things that would reference FPC to test. All I can recommend to the original poster RHollerich is to make sure the sources of FPC have not been altered. He might either restore a backup or reload a fresh copy of FPC 3.2.2 or what he uses then rescan FPC Tools -> Re scan FPC sources. And see if that corrected the problem. ---------------------------------------------------------------------- Martin_fr · 2023-06-29 10:21 Quote from: BrunoK on June 29, 2023, 12:06:19 pmQuote from: Martin_fr on June 29, 2023, 10:37:05 amWell, about "can compile" => the rtl is not compiled by the IDE except if I decide to do it. All the units are build already as ppu. You would need no build fpc (using make).Are you taking me for a beginner ? Neither yes, nor no. I don't usually research each poster to find indications of their knowledge level. I may now, after your statement, for some time (depending on how often I will have to recall that stated knowledge) remember that you are aware of the working of the fpc make progress and the IDE project build process.... But otherwise, my reply was based on a statement that based on what I perceive as "an average knowledge" could have been made in ignorance of the fact that those files would not be recompiled. (for testing). So then you have a reproducible bug. Which I understand is as follows: - build a modified rtl, with the change you indicated.  (this only needs to compile / it does not need to function) - build a project (sample project not yet supplied) to prove it compiles with the modified rtl - use codetools, and find it fails. If you did (what I have heart other people do) take a copy of the fpc file, and modified it out of place, and compiled it... Then there are various thinks to be checked (which you may have done / but I don't know). - systemh.inc appears to be part of the system unit? THen all other units depend on it, and compiling (for testing) would have meant only to use units that were rebuild with that modified system unit? I assume you took care of that. - I assume you did set up all paths (including to fpc sources) so codetool only got to see units that were tested with that modified system? Otherwise, if codetool saw other units, I would assume that to be considered a wrong config. Again, you probably did that. (despite that likely needs codetool knowledge, of which I have no statement what your level is) ---------------------------------------------------------------------- JuhaManninen · 2023-06-29 10:28 Quote from: BrunoK on June 29, 2023, 12:06:19 pmCodeTools also reads the FPC source to find declarations when using Ctrl-Click and apparently stops if something is wrong in the FPC source syntax without any indication of what happened. For curiosity, this is a big difference between Lazarus Codetools and the equivalent parser in Delphi. Delphi's parser reads compiled .dcu files while Codetools read Pascal source. Delphi's parse tree gets corrupted after an intense coding session and then Delphi must be restarted. Codetools recover from syntax errors once they are fixed. Actually it works relatively well with code that is being edited and thus temporarily broken. But yes, Codetools should point an error deep in unit dependencies better. I have experienced the same problem, not knowing what made Codetools stop. I last worked with Delphi about 10 years ago. Maybe their parser improved since then, I don't know. ---------------------------------------------------------------------- BrunoK · 2023-06-29 11:31 Quote from: JuhaManninen on June 29, 2023, 12:28:23 pmBut yes, Codetools should point an error deep in unit dependencies better. I have experienced the same problem, not knowing what made Codetools stop. I have been crippled with this from last week-end to Tuesday, switching and recompiling diverse older versions with no success until by luck I thought about the FPC sources that luckily were under SVN control. That is a bit the problem with my laptop and the touch pad under the keyboard, very easy to involuntarily mistype somewhere unexpected and not notice at once. QuoteI last worked with Delphi about 10 years ago. Maybe their parser improved since then, I don't know. I worked for a living with delphi from Delphi 3 to BDS 2006 until around 2015, then switched progressively to Lazarus. ---------------------------------------------------------------------- RHollerich · 2023-07-05 15:31 FYI: Using the info you guys provided, I determined the problem was caused by an earlier version of the Indy files. I had to go back three versions of my program before Ctrl-click starting working and jumping to the correct places. When I did a compare of those source files with the source files from my next program version, I noticed that a lot of the Indy files were different. By leaving the "old" Indy files as is, I was able to move all my changes done in the newer versions back into the program and still have the Ctrl-Click work. As soon as I tried to change the Indy files, it started failing again. Once I started checking the Indy files, in the software where Ctrl- Click worked, I was using Indy version 10.6.2.5451. In the software that Ctrl_Click failed, I was using Indy 10.6.2.0. However, I did not bother determining what file/or files caused the problem in Indy 10.6.2.0. I just went back to using 10.6.2.5451. And I have no idea why I had switched to the earlier version of Indy in the first place, but that was definitely an error on my part. Note: I am not compiling the Indy components into the Lazarus IDE. I just added the source folder which contains the Indy files into the program settings, so the compiler/IDE can find them. ---------------------------------------------------------------------- RHollerich · 2023-07-05 15:41 Actually, the version that was failing might be the newer version. When I look on "https://github.com/IndySockets/Indy", which appears to still be the current location for Indy, the version info in idVer.inc does show 10.6.2.0. So I am not sure how to figure out which is the newer version of Indy and which isn't. ---------------------------------------------------------------------- JuhaManninen · 2023-07-06 05:30 @RHollerich, are you sure there is no indication of the error location in the messages window? What if you open the Indy source files one by one and try to do something there? I found a similar bug report :  https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39872 Do things work if you install Indy from OPM and use it in your project? It is the recommended and easiest way to use a package. No need to adjust project settings. ---------------------------------------------------------------------- BrunoK · 2023-07-06 08:32 Actually, the messages window shows 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 Codetools, Errors: 1classes.pp(36,10) Error: expected =, but thod foundin the tested case, I "accidentally" introduced an error in the line 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 TWndMe thod = procedure(var msg : TMessage) of object;now I'm aware of that possibility, I'm better equipped (GIT on fpc) to identify and repair the incident but otherwise I is a surprising message. There does not seem to be a better solution than display the error in the messages window. ---------------------------------------------------------------------- RHollerich · 2023-07-06 15:04 Using the info you guys provided and the info in the link provided by JuhaManninen, I finally figured out how to display the codetool errors. Note: For those who are wondering how to get the Codetools messages to appear in the message window, I found a call in my code where Ctrl-Click wasn't working, then added a new line, typed in the same variable name, followed by a "." then waited for the popup window to appear to show the available options. It was at that point where the Codetool message appeared in the Messages window. As for the problem I was having, it appears to be in IdGlobal.pas. There is a line in that file (line 1986 in my copy) that looks like: 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   GOffsetFromUTC: TDateTime = 0{$IFDEF HAS_DEPRECATED}{$IFDEF USE_SEMICOLON_BEFORE_DEPRECATED};{$ENDIF} deprecated{$ENDIF};When I click on the error in the message window, the cursor ends up at the beginning of the final "deprecated". When I checked the Indy version that works, that line was commented out and replaced to look like this: 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   //GOffsetFromUTC: TDateTime = 0{$IFDEF HAS_DEPRECATED}{$IFDEF USE_SEMICOLON_BEFORE_DEPRECATED};{$ENDIF} deprecated{$ENDIF};  GOffsetFromUTC: TDateTime = 0; //deprecated;Note: I have no idea if this code was there originally, or if I had changed it earlier to make it work way back when. When I made that change in the newer version to match the older version and did a clean and rebuild, Ctrl-Click started working. Thanks for all the help in pointing me in the right direction. ---------------------------------------------------------------------- JuhaManninen · 2023-07-07 07:41 Quote from: RHollerich on July 06, 2023, 05:04:10 pmAs for the problem I was having, it appears to be in IdGlobal.pas. There is a line in that file (line 1986 in my copy) that looks like: 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   GOffsetFromUTC: TDateTime = 0{$IFDEF HAS_DEPRECATED}{$IFDEF USE_SEMICOLON_BEFORE_DEPRECATED};{$ENDIF} deprecated{$ENDIF};When I click on the error in the message window, the cursor ends up at the beginning of the final "deprecated". FPC does not want a semicolon there. I tested with {$mode objfpc} and with {$mode delphi}. This compiles : 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  var GOffsetFromUTC: TDateTime = 0 deprecated;In some other places (properties) a semicolon is needed but not with a variable. Why does Indy have a USE_SEMICOLON_BEFORE_DEPRECATED define? In what situation is it needed? And why does it have a HAS_DEPRECATED define? Is variable GOffsetFromUTC deprecated sometimes but not always? Makes no sense! I used Indy many years ago. The code was messy then and apparently has not improved. When most of a single code line is occupied by IFDEFs and ENDIFs, it becomes difficult to read. ---------------------------------------------------------------------- bytebites · 2023-07-07 09:02 Old discusssion https://forum.lazarus.freepascal.org/index.php?topic=34715.0 ---------------------------------------------------------------------- JuhaManninen · 2023-07-07 15:34 Quote from: bytebites on July 07, 2023, 11:02:21 amOld discusssion https://forum.lazarus.freepascal.org/index.php?topic=34715.0 OK. Some very old FPC versions required the semicolon. Indy developers should clean their code and remove such old leftover defines.