How to reproduce this Code Completion bug?

Question

I'm having a bug on Delphi XE2 (Update 4 Hotfix 1), which reproduces many times on the legacy project I work (it evolved from D6 to D7,D2006 and finally XE2), but I didn't know how to trigger it in a smaller project.

The latest time, it triggered on creating an event handler for a "hidden popup" on the app. When I click on the menu option to create the Click handler this happens.

pprocedure TMainForm.Blablabla1Click(Sender: TObject);
begin

end;

rocedure TMainForm.FormActivate(Sender: TObject);

You can see that the IDE inserted the new code INSIDE the declaration of the next method... But it's not all. Almost all times, on the DPR, code gets mangled too:

  AApplication.CreateForm(TDM_DataAcc, DM_DataAcc);
  AApplication.CreateForm(TMainForm, MainForm);
  pplication.CreateForm(Tfrm_login, frm_login);
  f frm_Login.CanLogin = mrOK then Application.Run

(It's almost like that, I don't remember if the 3rd Application.CreateForm get its' 'A' clipped or not, the other I'm sure are doubled and the IF gets its' "I" clipped).

Chasing on QualityCentral doesn't help (found nothing). This also happens sometimes on Class Completion(Ctrl-SHift-C).

Someone knows what triggers that bug, so I can create an new application and send it to Embarcadero?

I have seen that happen too. Especially the first example you give. And I know it wasn't because of miscounts in characters in the file as my sources are ANSI only and are always created with CRLF pairs. IDE was D5 or D6, but have seen it in D2009 as well. — Marjan Venema

Rob Kennedy Rob Kennedy · Accepted Answer · 2013-01-09T18:59:47

Behavior like that suggests that the IDE is miscounting characters in the file. There are several "file oddities" that the developers might not have anticipated and that could cause a character index to be miscalculated.

Check your file for unusual line endings. For example, a line missing a carriage return will appear correctly in the editor, but can cause incorrect line numbers elsewhere in the program.
Non-breaking spaces are another kind of character that will appear normally, and maybe even parse correctly, but occupies multiple bytes when represented in UTF-8 when the "normal" version of the character (a regular space) only takes up one. You will sometimes acquire such characters if you copy code from a Web browser.
Incorrect byte-order marks for UTF-8 or UTF-16 source files might also cause problems.

Often, opening your source file in Notepad or a hex editor will help you identify these problems.

How to reproduce this Code Completion bug?

1 Answers