Unable to use "Go to Definition"

[Stefan Pendl]

I am using PellesC 5.00.8 32-bit and 64-bit, but I am not able to use "Go to Definition of:" from the context menu of the IDE.

I can successfully launch the header files from the context menu of an "#include ..." line using the "Open file:" entry.

I can not access any function declared in the header files using the context menu entry "Go to Definition of:", this raises the error: "Error reading from file ... . The system can not find the file specified."

I have already rebuild the browse database, but no luck.

I can successfully build a project containing any function declared in the header files.

I am running the 32-bit version on WinXP Pro and the 64-bit version on WinXP Pro x64 Edition.

[Pelle]

The only thing I can think of right now is a path problem. I don't want to store a full path in the browse database, so the browse manager builds and stores a relative path. The IDE later attempts to recover the full path before loading such a file. Possibly this fails for some reason (I have never seen this myself).

In Tools -> Options, General tab, there is a checkbox for "Show full path for filenames". When this is enabled, the error box should include the full file path. If so, does it look like a valid path on your system?

[Stefan Pendl]

Hi Pelle,
if I enable this option, I still get a relative path, the part referenced as %ProgramFiles% or %ProgramFiles(x86)% is missing.

Instead of c:\programme\pellesc\include\stdbool.h, I only get pellesc\include\stdbool.h for the bool type

[Pelle]

OK. For a browse symbol associated with the "system", the IDE will use the INCLUDE environment value (see: Tools -> Options, Folder tab, Type: includes) and the SearchPath() API function to get the full path of the filename from the database (for a symbol associated with the project, the IDE will try to match the name against all known project files - to get the full path).

In other words, "Go to definition of: xxx" will use different functions in the IDE depending on where the symbol is defined. Is "Go to definition" always broken for you, or does it work for a symbol defined in your project, for example? I need to narrow the problem down, since I'm guessing too much at the moment...

[Stefan Pendl]

Hi Pelle,
attached find two simple projects, which fail to look up definitions.

As I can tell this is failing for any path, since I only use the main include and library folder definitions.

[Pelle]

OK, thanks.

I have only tried with the 64-bit version, but...

if I rebuild the project, to fill the project-specific browse database, I can go to definition of "DescrItems" (for example) without problems. I can also go to definition of "false" (for example) without problems - using *my* version of the system browse database. I don't see any project-specific functions in the sample, so I can't test that. I see several C runtime functions, but there is no "Go to definition" for them, rather the more helpful "Help about: xxx".

I obviously don't have the same machine as you, but I can't immediately find a problem here...

( not sure why, or if it matters, but the X86 project is refering to "C:\Programme\..." while the X64 project is refering to "C:\Program Files\..." - are we talking about *two* machines? )

[Stefan Pendl]

( not sure why, or if it matters, but the X86 project is refering to "C:\Programme\..." while the X64 project is refering to "C:\Program Files\..." - are we talking about *two* machines? )

The 32-bit version is build on Windows XP Pro German, where the 64-bit version is build on Windows XP Pro x64 Edition, which only contains a German MUI.

I have already tried to delete the .tab files and rebuild to update them, but no success either.

One thing to mention I forgot, the project folders are located on a network share, which is mapped to drive K:, but that should not matter, I think.
The full path to the projects would be:K:\eds_config\ufunc\x86\{project} and K:\eds_config\ufunc\AMD64\{project}
I do have full rights for this share.

[Pelle]

I have already tried to delete the .tab files and rebuild to update them, but no success either.

OK, and if you should try "pobr /F somename.tag /L" from the command line - do you see anything in those files?

One thing to mention I forgot, the project folders are located on a network share, which is mapped to drive K:, but that should not matter, I think.
The full path to the projects would be:K:\eds_config\ufunc\x86\{project} and K:\eds_config\ufunc\AMD64\{project}
I do have full rights for this share.

It shouldn't matter, AFAIK (but I can't test a share right now)...

[Stefan Pendl]

I listed the contents of the sysdefs.tag file, since I only use the main folder definitions, not separate ones for each project.
The content listed was as I would expect.

...
pellesc\include\stdbool.h(2) _STDBOOL_H (#define; ):
pellesc\include\stdbool.h(14) __bool_true_false_are_defined (#define; ): 1
pellesc\include\stdbool.h(11) bool (#define; ): _Bool
pellesc\include\stdbool.h(12) false (#define; ): 0
pellesc\include\stdbool.h(13) true (#define; ): 1
...

I am using 64-bit Pelles C on Windows XP x64 as a different user, than the 32-bit Pelles C on Windows XP, so there are no problems regarding the sysdefs.tag file in the users profile folder.

Pelles C is installed under C:\Program Files\PellesC or C:\Programme\PellesC

[Pelle]

Hmm... well, I have no bright ideas right now. I can't really see how information can make it into the database, but not out of it...
( I have tried changing various settings, but it still works here ... )

[Stefan Pendl]

Just checked at home and it works, but I only have local drives.
Will have to check, if it works on local drives at the company too.

Will post back the results, but that will be first possible on Monday next week.

[Stefan Pendl]

Just tested at the company and even if the project is located on a local drive this fails

Seems I have to live with this, had no problems with PellesC 4.5

[Stefan Pendl]

I have reinstalled Pelles C and things worked, before I customized the library and include folder definitions.

After I had added an additional path to the library and include folders, things stopped working once more.

Seems there is something wrong, if user defined folders are added in the general folder definition.

I need to check, if the problem persists, if the folders are only added at project level.

[Stefan Pendl]

I have tested further and if I remove the custom folders from the general include and library folder definition, things begin to work once more.

The problem now is, that the custom header files are not part of the sysdefs.tag file, so I can not go to their definitions.

If possible I would like to include the custom folders in the general definitions, since the majority of my projects use these custom folders.

[TimoVJL]

How about using pobr.exe ?