Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2008-09

: Code tools bug: with Code completition

12 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Luca Olivetti

En/na Mantis Bug Tracker ha escrit:

The following issue has been RESOLVED.

I hate it when you cannot add a note to a closed bug >:-(

Show quoted text 19 lines
---------------------------------------------------------------------- (0022497) Luca Olivetti (reporter) - 2008-09-29 17:09 http://bugs.freepascal.org/view.php?id=12254#c22497 ---------------------------------------------------------------------- I see the same message the 3rd time I ctrl+click on an identifier if it has to open the unit: 1) first ctrl+click over, e.g. TStringGrid, opens the unit grids.pas ok 2) I close the tab with grids.pas 3) ctrl+click on the same identifier, again it opens grids.pas ok 4) close the tab again 5) ctrl+click again, it opens the tab but it's empty and I see the same error (C:\lazsvn\lcl\grids.pas(-1,0) Error: no pascal code found (first token is ) from this point every ctrl+click on any identifier (even identifiers declared in the same unit) will bring up the same empty tab and the only way out is restarting lazarus (closing and reopening the project has no effect).

With revision 16806 this doesn't happen anymore *but* every other ctrl+click puts the cursor at the beginning of the unit instead of where TStringGrid is declared, i.e. at step 5) the tab is correctly opened with the full content of grids.pas but the cursor is on the first line of the unit.

Bye

Luca Olivetti Wetron Automatizaci?n S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007

Reply by email

Graeme Geldenhuys
to Luca Olivetti
Luca Olivetti wrote
En/na Mantis Bug Tracker ha escrit: > The following issue has been RESOLVED. I hate it when you cannot add a note to a closed bug >:-(

I second that!! Many times, due to email lag, the bug report is marked as resolved, before I could write a comment. And because I am not the original report, there is nothing I can do. :-(

This is not a selected case, it has happened over and over again. And from Luca's response, I am clearly not the only one.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Vincent Snijders
to Luca Olivetti: En/na Mantis Bug Tracker ha escrit: I hate it when you cannot add a note to a closed bug…
Luca Olivetti wrote 7 lines
En/na Mantis Bug Tracker ha escrit: > The following issue has been RESOLVED. > ---------------------------------------------------------------------- > (0022497) Luca Olivetti (reporter) - 2008-09-29 17:09 > http://bugs.freepascal.org/view.php?id=12254#c22497 > ---------------------------------------------------------------------- With revision 16806 this doesn't happen anymore *but* every other

And with r16808?

Vincent

Reply by email

Luca Olivetti
to Vincent Snijders

En/na Vincent Snijders ha escrit:

Show quoted text 10 lines
Luca Olivetti schreef: > En/na Mantis Bug Tracker ha escrit: >> The following issue has been RESOLVED. >> ---------------------------------------------------------------------- >> (0022497) Luca Olivetti (reporter) - 2008-09-29 17:09 >> http://bugs.freepascal.org/view.php?id=12254#c22497 >> ---------------------------------------------------------------------- > With revision 16806 this doesn't happen anymore *but* every other And with r16808?

I just updated to the latest one (16814) and, yes, it does the same. However, I found that it doesn't happen with every declaration, e.g. ctrl+clicking on TForm (that opens forms.pp) works every time, while TEdit or TStringGrid have the problem.

Bye

Luca Olivetti Wetron Automatizaci?n S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007

Reply by email

Vincent Snijders
to Luca Olivetti
Luca Olivetti wrote 15 lines
En/na Vincent Snijders ha escrit: > Luca Olivetti schreef: >> En/na Mantis Bug Tracker ha escrit: >>> The following issue has been RESOLVED. >>> ---------------------------------------------------------------------- >>> (0022497) Luca Olivetti (reporter) - 2008-09-29 17:09 >>> http://bugs.freepascal.org/view.php?id=12254#c22497 >>> ---------------------------------------------------------------------- >> With revision 16806 this doesn't happen anymore *but* every other > And with r16808? I just updated to the latest one (16814) and, yes, it does the same. However, I found that it doesn't happen with every declaration, e.g. ctrl+clicking on TForm (that opens forms.pp) works every time, while TEdit or TStringGrid have the problem.

Create a new bug report.

Vincent

Reply by email

Luca Olivetti
to Vincent Snijders

En/na Vincent Snijders ha escrit:

Show quoted text 17 lines
Luca Olivetti schreef: > En/na Vincent Snijders ha escrit: >> Luca Olivetti schreef: >>> En/na Mantis Bug Tracker ha escrit: >>>> The following issue has been RESOLVED. >>>> ---------------------------------------------------------------------- >>>> (0022497) Luca Olivetti (reporter) - 2008-09-29 17:09 >>>> http://bugs.freepascal.org/view.php?id=12254#c22497 >>>> ---------------------------------------------------------------------- >>> With revision 16806 this doesn't happen anymore *but* every other >> And with r16808? > I just updated to the latest one (16814) and, yes, it does the same. > However, I found that it doesn't happen with every declaration, e.g. > ctrl+clicking on TForm (that opens forms.pp) works every time, while > TEdit or TStringGrid have the problem. Create a new bug report.

Done
http://bugs.freepascal.org/view.php?id=12269

Bye

Luca Olivetti Wetron Automatizaci?n S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007

Reply by email

Henry Vermaak
to Luca Olivetti
Luca Olivetti wrote
Done http://bugs.freepascal.org/view.php?id=12269

hmm, i see this bug report is closed, but i'm still getting errors that are related to this.

when i ctr-click on a unit in my uses clause, it doesn't find units in different directories from the unit i'm clicking on, even thought i've added all the paths to the source files in my compiler options (under "Other Sources"). is this known? this obviously makes the code completion almost unusable.

what i should probably explain is that these units don't get compiled, since they are already built and the ppu/o files are in a directory i specified under "Other Unit Files" in the compiler options.

the project compiles fine, though.

henry

Reply by email

Mattias Gaertner
to Henry Vermaak
Show quoted text 14 lines
On 30/09/2008, Luca Olivetti wrote: > > Done > http://bugs.freepascal.org/view.php?id=12269 > hmm, i see this bug report is closed, but i'm still getting errors that are related to this. when i ctr-click on a unit in my uses clause, it doesn't find units in different directories from the unit i'm clicking on, even thought i've added all the paths to the source files in my compiler options (under "Other Sources"). is this known? this obviously makes the code completion almost unusable.

The bug 12269 is about not clearing a cache. For example opening a file via find declaration, closing it, and opening the file again via find declaration.
It has nothing to do with 'units not found'.

what i should probably explain is that these units don't get compiled, since they are already built and the ppu/o files are in a directory i specified under "Other Unit Files" in the compiler options.

Please run the project / compiler options / test. Does it show warnings / errors?

Mattias

Reply by email

Henry Vermaak
to Mattias Gaertner
Mattias Gaertner wrote 6 lines
On Fri, 3 Oct 2008 13:29:35 +0100 The bug 12269 is about not clearing a cache. For example opening a file via find declaration, closing it, and opening the file again via find declaration. It has nothing to do with 'units not found'.

sorry, i correlated the two issues because both caused my identifier completion to fail.

Show quoted text 6 lines
> what i should probably explain is that these units don't get compiled, > since they are already built and the ppu/o files are in a directory i > specified under "Other Unit Files" in the compiler options. Please run the project / compiler options / test. Does it show warnings / errors?

no warnings (except duplicate ppu for apache units in fpc), the project builds fine. it's a similar situation as with fpc having its compiled units in one place, and the source in another. so i specify the unit dir as /path/to/compiledunits/$(TargetCPU)-$(TargetOS), and i specify the path to all the source so the ide can find it for completion, etc.

it just seems to be that it doesn't find the source if it's in a different directory to the source of the unit you are clicking on (does that make sense?).

henry

Reply by email

Mattias Gaertner
to Henry Vermaak
Show quoted text 12 lines
[...] >> what i should probably explain is that these units don't get >> compiled, since they are already built and the ppu/o files are in >> a directory i specified under "Other Unit Files" in the compiler >> options. > > Please run the project / compiler options / test. Does it show > warnings / errors? no warnings (except duplicate ppu for apache units in fpc), the project builds fine. it's a similar situation as with fpc having its compiled units in one place, and the source in another.

Pretty normal.

so i specify the unit dir as /path/to/compiledunits/$(TargetCPU)-$(TargetOS),

The macros are normal. But this looks like an absolute path. Maybe you meant compiledunits/$(TargetCPU)-$(TargetOS), relative to your package?

and i specify the path to all the source so the ide can find it for completion, etc.

What do you mean with specify?
In lazarus you use packages to specify paths. You hardly write paths yourself in the edit/combo boxes of the IDE.

it just seems to be that it doesn't find the source if it's in a different directory to the source of the unit you are clicking on (does that make sense?).

You can see the search paths via source editor / popup menu / file settings / unit info. The 'unit path' is given to the compiler, the 'source path' is an addition for the IDE. Both are normally defined by the compiler options.

Are you using a package?
Can you give some more details, what you want to do?

Mattias

Reply by email

Henry Vermaak
to Mattias Gaertner
Mattias Gaertner wrote
> the unit dir as /path/to/compiledunits/$(TargetCPU)-$(TargetOS), The macros are normal. But this looks like an absolute path. Maybe you meant compiledunits/$(TargetCPU)-$(TargetOS), relative to your package?

it is absolute, but it's the right dir (and the compilation works, for both archs).

Show quoted text 5 lines
> and i > specify the path to all the source so the ide can find it for > completion, etc. What do you mean with specify?

i add all source paths to the "Other Sources (used only by IDE not compiler)".

In lazarus you use packages to specify paths. You hardly write paths yourself in the edit/combo boxes of the IDE.

the package in question (fpgui) doesn't play well when i cross compile. it compiles the whole package every time i switch compiler (i386 to arm), which is annoying. doing it this way it will find the compiled fpgui units for whichever arch, and just compile my project. this works well, so no problems there.

Show quoted text 5 lines
You can see the search paths via source editor / popup menu / file settings / unit info. The 'unit path' is given to the compiler, the 'source path' is an addition for the IDE. Both are normally defined by the compiler options.

i've had a look at this "unit info" and all the paths are there and correct.

as i've said, it does find some of the units i ctrl-click on. but it seems random and i _think_ it only finds source in the same directory as the file i'm clicking on.

henry

Reply by email

Mattias Gaertner
to Henry Vermaak
Show quoted text 9 lines
On 03/10/2008, Mattias Gaertner wrote: >> the unit dir as /path/to/compiledunits/$(TargetCPU)-$(TargetOS), > > The macros are normal. But this looks like an absolute path. Maybe > you meant compiledunits/$(TargetCPU)-$(TargetOS), relative to your > package? it is absolute, but it's the right dir (and the compilation works, for both archs).

I doubt, that this is portable. How do you want to compile that on your next/other computer?

Show quoted text 8 lines
>> and i >> specify the path to all the source so the ide can find it for >> completion, etc. > > What do you mean with specify? i add all source paths to the "Other Sources (used only by IDE not compiler)".

Ok.

Note: The recommended way is to add the files to your package. Then the IDE will setup the paths automatically. And it can warn you about common misconfigurations.

Show quoted text 8 lines
> In lazarus you use packages to specify paths. You hardly write paths > yourself in the edit/combo boxes of the IDE. the package in question (fpgui) doesn't play well when i cross compile. it compiles the whole package every time i switch compiler (i386 to arm), which is annoying. doing it this way it will find the compiled fpgui units for whichever arch, and just compile my project. this works well, so no problems there.

Apparently there is a problem, because switching targets should not compile everything everytime.
The IDE compiles everything (-B switch), when something changed compared to the data in the .compiled file of the output directory. If you have one output directory for each target, then you have one .compiled file per target and thus switching between targets should not add the -B switch. Please backup a .compiled file, switch back and forth and compile again. Compare the new .compiled file with the backup. What difference do you see?

Show quoted text 11 lines
> You can see the search paths via source editor / popup menu / file > settings / unit info. The 'unit path' is given to the compiler, the > 'source path' is an addition for the IDE. Both are normally defined > by the compiler options. i've had a look at this "unit info" and all the paths are there and correct. as i've said, it does find some of the units i ctrl-click on. but it seems random and i _think_ it only finds source in the same directory as the file i'm clicking on.

Sending me an example project would help to solve the mystery. But with your absolute path names it will probably not work here anyway.

What OS and what FPC version are you using?

Mattias

Reply by email