이 버그는 아주 특이한 조건에서만 발생하기 때문에 대부분의 개발자들에게는 별 상관이 없겠습니다만… 기록삼아 적어둡니다.

폼에 TRichEdit를 놓고, 아래와 같이 몇가지 속성들을 조정합니다.

이 상태로 컴파일하고 실행해보면, 분명히 디자인시에 리치에디트에 아무런 내용을 넣지 않았음에도 실행된 프로그램에서는 다음과 같이 깨진 문자열이 나타납니다.

보시다시피, 최신 버전인 델파이 XE5까지 포함해서 델파이 2007 이상 모든 버전에서 발생하고, 윈도우 버전과도 무관하게 동일하게 나타납니다. 다만 2007 버전에서는 깨진 한자들 대신 rtf 포맷 형식의 문자열이 나타나고요. 어쨌든 입력하지 않은 문자열이 툭 튀어나오는 데에서는 마찬가지입니다.

이 문제는 델파이 7 이하 버전에서는 나타나지 않습니다. 아마도 이 문제는 델파이 자체의 문제가 아니라, Win32 컨트롤인 Richedit 2.0 컨트롤 자체의 버그인 듯 합니다. 델파이의 구버전들에서는 Richedit 1.0 컨트롤을 사용하니까요. 2007 버전에서 깨진 문자열이 다른 형식으로 나타나는 것은, Richedit 2.0 컨트롤이 유니코드 버전과 안시코드 버전이 있는데 2007 버전에서는 안시코드 버전을 사용하기 때문일 것입니다.

이 문제에 대한 완전한 해결책은 찾지 못했습니다. 아니 사실은, 너무 드문 케이스이기 때문에(HideSelection, HideScrollBars, PlainText, Lines.Text의 네 가지 속성이 모두 정확히 설정되어야만 재연됨) 굳이 완전한 해결책을 찾을 필요를 느끼지 못했습니다.

저는 이 버그를 얄팍하게(?) 회피하는 방식으로 넘어갔습니다. 즉, 이 리치에디트 컨트롤이 생성되고 로딩되는 시점까지 이 네 가지의 속성중 단 하나만이라도 값이 다르면 이 버그는 발생하지 않기 때문에, 딱 하나의 속성만 바꿔놓은 후 Form의 OnActivate 이벤트에서 실제 필요한 속성으로 설정해줬습니다. 이런 간단한 트릭만으로도 이 버그는 회피할 수 있었답니다.