Control+Click on function is not working in Delphi XE
Asked Answered
R

10

9

In Delphi 7 whenever I control+clicked a function/procedure it took me to that function/procedure. But it is not working in Delphi XE - at least not with all functions. I have a function called Associate in ExtUtils.pas The function is correctly compiled so the compiler can find the ExtUtils.pas (and of course the ExtUtils is added to the Uses clause and its folder its added in 'Library path'). But when I control+click the function or the unit name, it doesn't take me there.

Any way to fix this?


UPDATE1: Also, Control+Click on a function (declare in the current unit) does not move the cursor in the INTERFACE section where the function is declared.

UPDATE2:
I temporary put the ExtUtils unit in project's folder and now it works. So, the Control+Click by itself it works but it seems that the IDE has problems finding the unit even it its folder is present in Library Path and Browsing Path.

Similar reports:
http://webcache.googleusercontent.com
http://webcache.googleusercontent.com
http://cc.embarcadero.com/Item/28269
One report right here (see answers below)


New test:
I have fully uninstalled Delphi (and manually delete the files and registry leftovers). Then reinstalled again. NO additional tools except CodeSite were installed, not even the databases. Then I created a new project. It contains a button. When I click the button, it runs the TestMe procedure which is defined in an external PAS file called TestUnit.Pas. I added the path to this library in Library Path and Browsing Path. But the Control+Click on TestMe procedure is still not working! If I hover the mouse over the TestMe procedure, the pop-up says "Declared in TestUnit", where the 'TestUnit' word is a blue link. If I click it I hear a Windows system sound but the IDE doesn't take me there (to the unit).

The TestMe procedure is this:

procedure TestMe;
begin
  Beep(800, 500);
end;

If I control+click the Beep procedure, it takes me to Windows.pas. So, this is working. Please let me know if you have in mind a different test.

UPDATE:
And now it works! Without any apparent reasons! I just open and closed and compiled the project. But I make no changes to Delphi except these two: AutoSave options-> Editor files and Project Options.

UPDATE:
This cannot be!!!
So, now I can access the TestUnit.pas file when I control+click on TestMe procedure. So, I moved the original PAS file (ExtUtils.pas) that didn't wanted to work in my initial test (before Delphi reinstall) in the same folder where TestUnit.pas is. Guess what: I can open (with control+click) to TestUnit.pas but not the ExtUtils.pas!!!!
Delphi acts so strange and inconsistent!

UPDATE:
I edited ExtUtils.pas and now I cannot open AGAIN TestUnit.pas. Ken White won't let me say that Delphi could possible have bugs. So I cannot use the 'bug' together with 'Delphi'. Can anybody put these words together for me?

UPDATE:
I totally removed any reference to ExtUtils.pas - so I restored the project to the point where it worked (with TestUnit). But now the bug persists. Even if few seconds before it worked with TestUnit now its not working again.

UPDATE:
Now I realize an important thing: in my source code (in the test project) I have a single line of compilable code:

procedure TForm1.Button1Click(Sender: TObject);
begin
 TestMe;
end;

The blue dots does not appear for this code - as it wouldn't have been compiled. In those few minutes when the program worked, I have seen the blue dots. I have also excluded 'AutoSave options-> Editor files and Project Options' as a possible cause for this issue.

UPDATE:
I have found a way to fix the problem... for few minutes: I move the project and the library in a different folder (any location will do it). The control+click will work for a while. It even works if I put the files back into the original folder. So, it seems that Delphi keeps some kind of cache of some files. As long as the cache is broken and it keeps the cache, control+click won;t work. But when I move the files, it has to recreate that cache so it will work until the issue reappears and it is stored in the cache.

Reparation answered 6/6, 2011 at 16:42 Comment(7)
Please stop with the "nothing works" and "it's broken" and "it's a bug" posts. If this were an actual bug, it would be discussed in other places by other people. Since you appear to be one of the very few people experiencing it, it's most likely an issue with your project or your installation and not a bug.Expectoration
Well Ken, you said the same about some previous questions of mine until it was actually proved that there were indeed Delphi bugs (with other people reproducing them or with a link to the QC page of the bug). So maybe you should stop thinking that Delphi is free of bugs. Other people keep reporting them. Since I have already spent too much time trying to fix some issues that were actually bugs (see the background compiling bug for example), I will consider this a bug until I can find other reason for it.Idell
PS: Please let me know if StackOverflow has some specific rules against post as "Background compiling is not working" or "Control+Click on function is not working". Maybe you can point to them.Idell
PS: Looks like another problem I had recently was AGAIN a bug: #6252164. Oh my god, I said 'bug' again. Damn it.Idell
And because you said that nobody is having this issue except me, I just posted some links to web sites where people reported similar issues. One of them is a QC very similar with mine, right on Embarcadero web site!!!!!Idell
@Altar: I never said Delphi didn't have any bugs - all software has bugs. I said that every problem you have doesn't mean there's a bug in Delphi. For instance, you complained about AQTime not working, and the problem was that you didn't bother to read the documentation. That's not a Delphi or AQTime bug, is it? But you claimed it was. Screaming bug when it isn't one makes it look like Delphi (or any other software product) is really poorly done, and it does nothing else. If you can document bugs, get them into QC so they can be fixed, or vote for them to make them get fixed sooner.Expectoration
It seems as if I clean the Project, it has the same effect as if you move your folders.Orff
B
7

Here we are 5 developers using Delphi 2010 and 2 also using XE and we are experiencing the same thing with the Ctrl-click as you. It seems to stop working randomly. We never could find a pattern or a fix for that. So from time to time we hear swearing coming from cubicles...

When that happens, I use shift-ctrl-F, to do a search.

Sylvain

Becker answered 6/6, 2011 at 16:42 Comment(3)
Does the issue also fix by itself? About that pattern - I spend today about 4-5 hours reinstalling Delphi and then searching for a pattern. As you can see in my orig question I can fix the issue on demand but it then it reapers.Idell
One thing i found (using Delphi 2010) is that the problem can be sourcecode of the unit. E.g. CTRL+Click breaks when its missing a ; in the interface section, such as procedure foo x; while foo should have a ; suffix. The thing is that the compiler does not complain, and the IDE does not, but the code insight engine can not process it. I forgot what keyword x exactly was, but it is not deprecated, virtual, overload, or override..Twiggy
Revisiting this 5 years later, same problem, same codebase, againDelphi 2010. History does repeat. See shortcut workaround: https://mcmap.net/q/1144551/-control-click-on-function-is-not-working-in-delphi-xeTwiggy
C
3

I'm using Delphi 5 and the Ctrl-click have also problems, i don't know if it still working in the new delphi IDEs but i can go from declaration to implementation using CTRL-SHIFT-UpArrow or DownArrow. Hope it helps.

Chessy answered 6/6, 2011 at 16:42 Comment(1)
Nice! That works in Delphi 2010 (where CTRL+Click goes to wrong line)Twiggy
S
3

First, thanks for you all to give hints about this problem. Maybe this is a question long time ago, but at last, after tried many many times, I think the problem cause is, actually, in the "project source code"

IDE version: Delphi XE

please try:

  1. in the Project Options >> Delphi Compiler>>Compiling , ensure:

    Debug Information: true

    Symbol Reference Info: Reference info

  2. in the Project Source file(dpk file, open by Project >> View Source), remove {$REFERENCEINFO OFF} or change to {$REFERENCEINFO ON}

Note that step 2 is very important, even step 1 done, it still can not browse source without step 2.

Staid answered 6/6, 2011 at 16:42 Comment(0)
S
2

There have always been these two distinct options in Delphi:

  1. Library path – used when compiling your app.

  2. Browsing path – used by Code Insight, i.e. when control-clicking identifiers too.

You need to check the second one. It must include the path(s) to the source files you are trying to navigate with Ctrl+Click.

Swiss answered 7/6, 2011 at 7:57 Comment(2)
I just looked in Delphi 7 and there is no custom path in 'Browsing path'. It only contains the standard Borland paths - all starting with "$(Delphi)".Idell
I just added the path also to 'Browsing path' but it still not working. (I rebuilt the project and restarted the IDE also). Please see update2 in my orig question.Idell
M
1

I had just made a new groupproject with two projects in Delphi 11. After that I was having problem using Ctrl + Click to jump to functions. I right clicked the groupproject and did "Clean All" and then "Build All" after that it was working for me again.

Misuse answered 6/6, 2011 at 16:42 Comment(0)
T
1

For future reference. Using Delphi 2010 i have found that a ; preceding virtual in the interface section makes a difference;

function MyProc(): String;  overload; virtual;
function MyProc(): Integer; overload; virtual;
//                             >>   ^   <<

This ; character can break the CTRL+Click (code insight) functionality. Compiles fine nonetheless.

Twiggy answered 6/6, 2011 at 16:42 Comment(0)
F
1

I've found that if I use a record type in the interface section and it's not defined by a type expression, Ctrl-Click and other jumping functions (Ctrl+Shift+Up/Down) won't work.

type
  TForm1 = class(TForm)
  ...
  public
    Something:record
                A, B:integer;
              end;
    procedure DoSomething;
  end;

With the code above I can't jump to implementation of the procedure with Ctrl+Shift+Down. The fix I have to use:

type
  TMyRecord = record
                A, B:integer;
              end;

  TForm1 = class(TForm)
  ...
  public
    Something:TMyRecord;
    procedure DoSomething;
  end;

Tested with Delphi XE4.

Fimbriation answered 6/6, 2011 at 16:42 Comment(1)
+1. This construction disables method generation (Ctrl+Shift+C) as well. Second thing that eliminates all the handy navigation stuff is IFDEF's if you use constants or defines not declared in the same unit. Tested with XE2Wrapper
B
0

This happens to me quite often, specially when two IDE is opened at the same time.

The way I have found to fix this is:

  1. Clean your project.
  2. List item
  3. Close the IDE.
  4. With the Windows Explorer, navigate to your project.
  5. Search for *.dcu Delete all the .dcu
  6. Launch the IDE and load your project.
  7. Compile it.

At this point, the code navigation (Ctrl+Click) should work.

Beesley answered 6/6, 2011 at 16:42 Comment(1)
That was loong time ago. Now I use Delphi 10.4Idell
F
0

Solved!

It works for me, change the Code Insight type.

Fumatorium answered 6/6, 2011 at 16:42 Comment(1)
The bug was related to XE.Idell
O
0

(Symbol Reference info)This option has no effect unless Debug information and Local symbols (see above) are enabled.

Code completion and code navigation features (Ctrl+Click) work only when Symbol Reference info is set to Reference info.

Obsequies answered 6/6, 2011 at 16:42 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.