: Tools API 패키지 파일을 디버깅 하려면, DLL 패키지 자체가 RAD XE2 개발환경과 같은 컨텍스트로
: 돌아가기 때문에 RAD XE2 개발환경 자체를 Debbugee 타겟으로 올려줘야 하는데...
:
: 세컨드 RAD XE2 가 뜨면서 중간에 다운되네요...
:
: Visual Studio 에서 IDE 익스텐션 모듈을 디버깅 할 땐... Visual Studio 자체를 디버깅 해도
: 세컨드 IDE 가 정상적으로 올라오는데 RAD XE2는 왜 이러죠. 다른 분들은 잘 되나요?


XE2를 Repair 모드로 다시 설치하고, Update 3 도 다시 설치해주는 우아하지 않은 방법으로 해결 --;
뭐 이런 황당한 경우가 --;

세컨드 RAD XE2 인스턴스가 Debugge 타겟으로 로드될 때 불필요한 몇가지 예외들을 걸러주지 못하 더군요.
Tools API 패키지에 브레이크 포인트를 걸어서 소스레벨 디버깅 하려면 몇가지 사전작업들도 해줘야 하고.
Tools API나, Design Time 시의 컴포넌트 등을 소스레벨 디버깅 작업하기가 매우 번거롭네요.

Visual Studio 에선 IDE를 확장해주는 익스텐션 모듈을 디버깅 작업할 때 편리했는데. RAD XE2는 불편합니다.

XE2 IDE 자체를 디버깅 해보니까... RAD XE2 개발환경 자체가 델파이로 만들어 졌더군요.


화면에서 오른쪽이 메인 RAD XE2고, 왼쪽이 Debuggee 타겟으로 올라온 세컨드 RAD XE2 입니다.
캡쳐한 화면은 컴포넌트를 등록(Register)할 때, RAD XE2 개발환경이 어떤식으로 컴포넌트를 등록하게
되는지 IDE의 내부동작을 디버깅 하기 위해서 컴포넌트의 소스코드에 브레이크 포인트를 걸어 놓은 장면
입니다.

Debuggee 타겟으로 올라온 세컨드 RAD XE2 개발환경에서 Package를 인스톨 하면(Component -> Install Packag)
메인 RAD XE2 에서 패키지 소스코드에 브레이크 포인트를 걸어놨기 때문에, 세컨드 RAD XE2의 내부적인 동작을
디버깅 할수 있게 되는 거죠. Tools API 패키지도 이런 식으로 디버깅이 가능하게 됩니다.