Compiler messages and debugger is always 2 or 3 lines off the source. I doublechecked line endings already (even wrote a tool for that which found and fixes some). It seems to be a problem using generics in #XE6 .

-

Compiler messages and debugger is always 2 or 3 lines off the source. I doublechecked line endings already (even wrote a tool for that which found and fixes some). It seems to be a problem using generics in #XE6 .
The problem goes away if not using the generic type.

Comments

  1. Bert VerheesJune 23, 2014 at 7:38 AM

    It would be easy if they would adapt to occuring linebreak-conventions along systems.

    I had this issue too, years ago, Delphi doubled the linebreaks because accidently the sources were saved as UNIX-text.
    It costed me hours to get the code readable again.

    This should not happen in a matured (almost 20 years on the market) development environment.

    ReplyDelete
  2. Magno LimaJune 23, 2014 at 11:00 AM

    Open source with notepad plus and set to view all characters, sure you get the offending char. Save it and debug.

    ReplyDelete
  3. Bert VerheesJune 23, 2014 at 1:42 PM

    Yes Magno, it is doable.
    In my case, it were hundreds++ files.

    It could have been happened months before I discovered the problem at a restore of a file, and I discovered that all files had the same problem. Of course there was time pressure, there always is.

    It is years ago, and even now, I sometimes find files with the non-Windows-linebreaks.

    The point is, a good code-editor should solve this kinds of problems transparently, it is just a small code-change. Especially nowadays, when code is often exchanged between platforms.

    ReplyDelete
  4. Magno LimaJune 23, 2014 at 3:22 PM

    Bert Verhees Sure, a simple "view all chars" would solve. The same happen again to me yet this year.

    ReplyDelete
  5. Brian HamiltonJune 23, 2014 at 9:45 PM

    I have seen this problem where there is alot of code 
    it progressively gets worse the further down the code
    i.e to get run to cursor to work I would have to copy/paste that procedure closer to the start of the code source in the IDE

    ReplyDelete
  6. mezenJune 23, 2014 at 11:23 PM

    With "View / Show Symbol / Show all characters" in Notepad++ you only see all characters (surprise^^), but with "Edit / EOL conversion / Windows" you can set all line endings to CR LF

    ReplyDelete
  7. Steffen BinasJune 24, 2014 at 3:11 AM

    As I initially wrote: I did check the line endings before. I even wrote a tool for that. I now tried Jeroen Wiert Pluimers tool running over my complete code base but the result is the same. I'm pretty sure the line endings are not the problem. In my code the generic declaration of TTVRect is shown in the comment. If I move the declaration in the unit LineEndingTest the errors goes away. If use the TTVRect not inside a class (I tried a local function called in initialization) the error also goes away. I think here is happening something more complicated.

    ReplyDelete
  8. Magno LimaJune 24, 2014 at 5:40 AM

    Steffen Binas I had similiar issue, the problem was NOT with line endings format, as I told, check any non ASCII regular char into the code.

    ReplyDelete
  9. Jeroen Wiert PluimersJune 24, 2014 at 7:14 AM

    Steffen Binas that sounds like an encoding issue. What codepages of files and IDE were affected?

    ReplyDelete
  10. mezenJune 24, 2014 at 7:29 AM

    The IDE uses afaik UTF-8, so you could use unicode-chars in your source code. Alexander B. created a little crazy example with the right-to-left mark (http://en.wikipedia.org/wiki/Right-to-left_mark), where the source looked like "Button1.;()kcilC" and that compiled and worked.

    ReplyDelete
  11. Magno LimaJune 24, 2014 at 7:44 AM

    With me happened that a weird char was lost inside the code, out of any string, even
    the compiler was able to compile

    ReplyDelete
  12. Brian HamiltonJune 24, 2014 at 11:51 PM

    another quirk of the compiler that is still there...
    when I am reserecting dfm forms to marry to .pas files, i.e double click on a button to hook up the lost code to the procedure , if the button name does not match the procedure name as would be expected, then the compiler puts in an empty procedure...as it should...but corrupts the code..the and extra p is added to the word procedure and removed from the next procedure in the code

    ReplyDelete
  13. Bert VerheesJune 25, 2014 at 4:26 AM

    Hi Brian, I have the same, but in another occasion, and another word, but also with the letter p. It steals a p from the word Application and puts it in another word Application, and it happens sometimes. I learned to live with it, but it is buggy.

    Also the rename of refactor is not trustworthy. It once demolished a lot of code, by doing something very strange. I have never used it again, since.

    And when you paste in some code, it puts it at the beginning of the line, not on the indenting level where the code is. But happily, there is Ctrl+D to repair it.

    ReplyDelete

Post a Comment