Windows Form 프로그래밍을 처음 접하면, MFC에서의 지저분한 구조를 한번에 대체할 수 있을 것만 같은 느낌이 들지만, 실제로는 그렇지 않다. MFC 구조는 깔끔하지 못하다. 대표적으로, MFC는 윈도우로 가는 메세지를 모두 잡아내기 위해서 2개의 훅을 설치하는데, 그 중 하나는 WH_CBT라는, 이름부터 마음에 들지 않는 훅이다. CBT는 Computer Based Training의 약자인데, 이 훅의 목적은 윈도우의 작동 방식을 배우라는건가? 여튼, 이 훅을 설치해야 윈도우의 시스템 메시지까지 잡아낼 수 있다. 만들어진지 꽤나 오래되는 클래스 라이브러리이고, 구조로 봤을 때도 그렇게 깔끔한 라이브러리가 아니라서 항상 이런 저런 불만은 많았지만, 직접 클래스 라이브러리를 만들어보려고 하면 MFC 정도 되는 것도 만들기 힘들어서 그냥 쓰는 라이브러리인데..
이런 생각을 하던 사람이라면 Form 프로그래밍이 세상을 구원할 구세주처럼 보여지겠지만, 실제로 MFC를 대체할 수 없다. Form 프로그래밍이 C#에 최적화되어 있는 이유도 있고, 기능이 아직 MFC에 못 미친다는 현실적인 이유도 있다. (MFC 9.0, 그러니까 Feature Pack에서 새로 추가된 클래스들은 매력적이지만.. 아직도 MFC 구조에 매달려 프로그래밍해야 하나..) 더구나 MSDN에서 Form 관련 클래스는 찾기가 뭐가 이렇게 힘들어..
여튼, 다음 MSDN 문서는 MFC와 Form이 어떤 차이점을 가지고 있는지 알려주는 좋은 자료이다.
MSDN Document http://msdn.microsoft.com/en-gb/library/0xb61xs7(VS.80).aspx
이런 생각을 하던 사람이라면 Form 프로그래밍이 세상을 구원할 구세주처럼 보여지겠지만, 실제로 MFC를 대체할 수 없다. Form 프로그래밍이 C#에 최적화되어 있는 이유도 있고, 기능이 아직 MFC에 못 미친다는 현실적인 이유도 있다. (MFC 9.0, 그러니까 Feature Pack에서 새로 추가된 클래스들은 매력적이지만.. 아직도 MFC 구조에 매달려 프로그래밍해야 하나..) 더구나 MSDN에서 Form 관련 클래스는 찾기가 뭐가 이렇게 힘들어..
여튼, 다음 MSDN 문서는 MFC와 Form이 어떤 차이점을 가지고 있는지 알려주는 좋은 자료이다.
MSDN Document http://msdn.microsoft.com/en-gb/library/0xb61xs7(VS.80).aspx