올려주신 소스를 컴파일해봤습니다만 제 노트북에서는 재현이 안되는고로.. 짐작만 할 수 있겠네요.
김시환님도 마찬가지실 거 같습니다만, 제가 의심스러운 부분은 TPhotonGraph::Draw_BackGround() 함수입니다.
일단 BitBlt() 함수의 소스 DC에 NULL을 넣어서 호출하신 것이 어떤 결과가 나올 지 Win32 SDK에 정의되어
있지 않습니다.
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/bitmaps_0fzo.asp)

다시 말해서 Undocumented한 사용법이기 때문에, OS나 하드웨어(예를 들어 그래픽 카드)에 따라 다른 결과가
나올 수도 있습니다. BitBlt() -> Brush::Color -> FloodFill()을 차례로 호출하신 것은 아마도 해당 사각형
영역을 흰색 혹은 검은색으로 채우기 위해 그러신 것 같은데요, 제 생각엔 FillRect() 호출로 바꾸시는 것이
좋을 듯 하네요.

만약 위와 같이 해결이 안된다면, 서로 다른 결과를 내는 피씨의 하드웨어와 OS 사양을 비교해보는 것이
급선무이겠지요. 특히 그래픽카드의 종류, 그리고 95/98/ME 계열과 NT/2000 사이의 차이에 주혐의점을 주고요.

빌더의 버그일 가능성은 별로 높지 않아보입니다. 사용하신 정도의 코드는 저를 포함해서 수없이 많은 빌더
개발자들이 많이 사용하는 코드니까, 이런 버그가 있었다면 이전에 발견되어서 벌써 패치가 나왔겠지요.

제 경험에는, 예전에 많이 쓰이던 리바 TNT 카드에 브러시 관련 버그가 있어서 한번 난리를 쳤던 적이
있었습니다. 윈98에 리바 TNT 카드 피씨에서 브러시 카피만 쓰면 화면이 깨져버리는 하드웨어 버그였습니다.

먼저 말씀하신 스핀에디트 관련은... 일단 쓰레드가 의심스럽습니다. 쓰레드 내부에서는 Synchronize를 사용하는
경우를 제외하고는 스핀에디트 등 비주얼한 컴포넌트에 접근해서는 안됩니다. 말씀하신 경우처럼 비상식적인
의외의 경우가 발생합니다. 다른 컴포넌트로 바꾸었더니 제대로 동작한다고 해서 스핀에디트의 문제라고 보기는
좀 그렇지요. 쓰레드내에서의 안전성은 컴포넌트마다 똑같을 수는 없으니까요.

만약 쓰레드 내부에서 접근한 경우가 아니라면, 옵티마이저 버그일 가능성도 있습니다. 모든 C++ 컴파일러들은
저마다 하나둘씩 옵티마이저 버그를 가지고 있는데, 물론 컴파일러마다 증상은 다 다르지요. 문제가 발생하면
프로젝트 옵션의 옵티마이즈 옵션을 꺼놓고 다시 해보시면 옵티마이저 버그인지 확인할 수 있습니다.

그럼...


김시환 님이 쓰신 글 :
: 빌더 3.0으로 시작해서 6.0까지 오직 하나의 툴을 고집하며 줄기차게
: 개발해 왔는데 최근들어 너무 어이없는 빌더 컴포넌트의 버그들을 보면서
: 조금 답답한 심정을 올립니다. 이 글을 읽고 계신 분들 중에 혹시 같은 경험을
: 했거나 혹은 할지 몰라서 제가 경우를 몇자 적어 봅니다.
:
: 2번의 경험은 이미지 컴포넌트를 사용했을 때 발생했습니다.
: 증상은 동일한 코드로 컴파일한 실행화일에 동일한 데이타를 가지고 처리했을 때
: PC에따라 2가지의 결과가 나타나는 경우입니다.
: 분명 내가 쓰던 PC에서 문제가 없어 넘겨준 코드가 다른 PC에서 다른 결과를 나타내고
: 있는 것이었습니다.
:
: 이번에 경험한 것을 SpinEdit 컴포넌트를 사용하고나서 발생한 문제 입니다.
: 이것도 PC마다 다른 경우가 나타나는지는 테스트 할 수 없었지만 SpinEdit를 EditBox로
: 바꾸면서 문제가 없어 졌습니다.
:
: Form1->spinedit1->Value = g_LD.x ;
: Form1->spinedit2->Value = g_LD.y ;
:
: Form1->spinedit3->Value = g_SUB.x ;
: Form1->spinedit4->Value = g_SUB.y ;
:
:
: 위와 같은 코드가 있었는데 위의 코드는 쓰레드에서 바뀌는 위치를 표시하는 부분이었는데
: 특정한 순간에 2번째 라인을 실행을 하게 되면
:
: g_LD.x = 4, g_LD.y = 1 의 값을 가지고 있었을 경우
:
: Form1->spinedit1->Value  ->  4 , g_LD.x  -> 4
: Form1->spinedit2->Value  ->  1,  g_LD.y  -> 4  메모리의 값이 이런식으로 값이 변합니다.
:
: 3,4 번째 라인에는 문제가 물론 없고요..
:
: 디버그를 하면서 CPU의 어셈코드를 따라가 보니 SpinEdit의 SetText 멤버 함수를 호출하는
: 부분에서 spinedit1->Value 값이 g_LD.y 로 들어가고 있었습니다. 황당 그 자체였습니다.
:
: 첨부로 올린 소스는 위의 예는 아니고 2번째 경험했던 문제의 코드 입니다.
: 원래 컴포넌트를 개발하려다가 제가 컴포넌트 만들어 본적이 없어서 일단 급한김에 이미지
: 컴포넌트를 이용해서 만들어 사용하던 것이었는데
:
: Graph라는 버튼을 누르면 데이타 화일을 읽어서 4개의 그래프를 그립니다.
: Print라는 버튼을 누르면 화면을 프린트 할때 토너절약을 위해 그래프 바탕을 흰색으로
: 바꾸는 역할입니다.
: 그리고 4개의 체크박스는 각각의 그래프를 숨기거나 나타내기 위해 사용됩니다.
:
: 문제는 체크박스를 사용했을 때 그래프의 바탕화면의 색에는 영향을 미치지 않고 단순히
: 그래프만 사라지게 하는 것인데 이게 PC에 따라 특정 PC에서는 바탕을 희게 만들어 버립니다.
:
: 한번 코드를 보시고 혹시 제가 잘못한 부분이 있으면 찾아서 지적해 주시면 감사하겠습니다.
:
:
:
:
:
: