The second most annoying is when code completing fails after a debug has been terminated, and you try to write variable[dot] to get a method or property, and it believes what ever word that is first on the next line is supposed to be added after the [dot] and fails. A recompile fixes the code completion.
Lars Fosdal Code completion (and Code Insight) may fail just after recompiling. I’ve got this problem not long ago – When I see it fails, I delete *.dcu and *.identcache, use Code Insight for a while, but after compiling the project it fails again.
Always wondered why they didn’t just find a way to extract the parser from the compiler into a library and use it for both the compiler and the IDE. Why have a separate parser for Code Insight and Error Insight?
The answer to that is “They could, but it would be an incredibly large amount of work for the compiler team, and would delay other more important features”.
I know the answer because I tried to make it happen during my tenure, but couldn’t. Alas.
Kenneth Cochran It took MS until VS2012 to do the same with VC++, so it’s not a trivial task. While C++ is clearly a more complex language, MS is quite a bit larger than Borland/CG/EMB, so I think that evens it out.
This is caused by several things: a. different parser for error insight. b. different search paths for error insight versus real compiler. Most likely it’s a, but if it’s b you can actually do something about it.
This is one of the most annoying error of the IDE.
ErrorInsight => Error Inside
This error is not XE3-specific – it already has a long history -.-
The second most annoying is when code completing fails after a debug has been terminated, and you try to write variable[dot] to get a method or property, and it believes what ever word that is first on the next line is supposed to be added after the [dot] and fails. A recompile fixes the code completion.
Reduces still further any desire I might feel to “upgrade”.
i think Linux+Lazarus is a cure for this?
ErrorInsight never worker properly AFAIR. The first thing every Delphi developer should do is to turn it off.
Paulo Silva – That cure is worse than the ailment 😛
Linas Naginionis – Well, when it works, it is nice.
Lars Fosdal Code completion (and Code Insight) may fail just after recompiling. I’ve got this problem not long ago – When I see it fails, I delete *.dcu and *.identcache, use Code Insight for a while, but after compiling the project it fails again.
Just ignore whenever it happens 🙂
Next week – when Delphi gets opensourced – you can go fix it yourself.
Just kidding.
Hit that little – in the box near the word “Errors”.
Always wondered why they didn’t just find a way to extract the parser from the compiler into a library and use it for both the compiler and the IDE. Why have a separate parser for Code Insight and Error Insight?
I just ignore that box alltogether.
Kenneth —
The answer to that is “They could, but it would be an incredibly large amount of work for the compiler team, and would delay other more important features”.
I know the answer because I tried to make it happen during my tenure, but couldn’t. Alas.
Kenneth Cochran It took MS until VS2012 to do the same with VC++, so it’s not a trivial task. While C++ is clearly a more complex language, MS is quite a bit larger than Borland/CG/EMB, so I think that evens it out.
This is caused by several things: a. different parser for error insight. b. different search paths for error insight versus real compiler. Most likely it’s a, but if it’s b you can actually do something about it.
Nick; and the number of half-baked features keeps growing… 🙁
I don’t think you can blame two different parsers for TStringList not having a member named ‘Free’. That’s just pathetic.
After being spoiled with VS, Delphi IDE now seems a bit too Notepad-ish to me.
There is a cmd line argument (do not remember which) to disable all background parsers in the IDE. That is the most reliable way of using it in IMHO.
Alexandru Ciobanu Would be nice to disable only this one, without turning off everything