728x90


EditBox, ListBox, Static Text, Radio Button 등 컨트롤의 배경을 투명하게 만들고 싶을 때에는 다음과 같은 작업을 해줘야 한다.



1. 컨트롤의 속성에서 Transparent를 True로 변경해준다.



2. stdafx.h 에 다음과 같이 라이브러리를 추가해준다.



3. 투명하게 할 Item이 있는 Dialog의 OnInitDialog()에 다음과 같이 추가해준다.



4. 투명하게 할 Item이 있는 Dialog의 OnCtlColor()에 다음과 같이 추가해준다.


nCtlColor의 종류는 아래와 같다.
#define CTLCOLOR_MSGBOX         0
#define CTLCOLOR_EDIT               1
#define CTLCOLOR_LISTBOX          2
#define CTLCOLOR_BTN               3
#define CTLCOLOR_DLG               4
#define CTLCOLOR_SCROLLBAR     5
#define CTLCOLOR_STATIC           6


ps. 왜인지 모르겠지만, CTLCOLOR_BTN(버튼) 의 경우에는 적용이 되지 않는다.

728x90
728x90

OpenAL(Open Audio Library)는 OpenGL과 같이 Free Lisence 이다.

3D Sound 까지 지원하고, 멀티 플랫폼까지 되므로 많은 사람들이 사용하고 있다.

기본적 파일은 wav 파일을 사용하고 있다.



다운로드 주소 : https://www.openal.org/downloads/

728x90

'Game Programming > OpenAL' 카테고리의 다른 글

OpenAL - OpenAL을 이용한 사운드 재생  (0) 2017.11.19
728x90

C++ 에서는 명시적으로 클래스의 상속을 막는 방법이 없기 때문에 final 이라는 키워드가 추가되었다.


final 키워드

이 키워드는 클래스에 사용하면 클래스를 상속할 수 없고, 함수에 사용하면 함수를 상속할 수 없다.


아래 사진은 클래스에 final을 붙였을 때 이다.


아래 사진은 함수에 final을 붙였을 때 이다.



override 키워드

이 키워드는 클래스 함수의 오버라이드를 막을 때 사용된다.


아래 사진은 함수에 override를 붙였을 때 이다.



728x90
728x90

서로 분할 작업을 하면서 모듈을 개발하다보면, 어떤 함수는 추가가 되고 어떤 함수는 없어지고 할 것이다.


이럴 때, 내가 만든 모듈에서 없어진 함수가 있다면 그것을 사용하는 개발자에게 경고를 띄워주고 싶을 것이다.




deprecated (함수 사용 경고) 이 키워드를 사용하면 된다.



사용법은 아래와 같다.








출처 : https://msdn.microsoft.com/ko-kr/library/044swk7y.aspx

728x90
728x90

리팩토링을 어떨 때 시작하고 어떨 때 그만둬야 할지 판단을 해야하는데, 그것은 사실 상 경험을 많이 해봐야 하는 부분일 것이다.



그냥 가볍게 보통 이럴 때 리팩토링을 어떻게 하고, 이럴 때에는 이렇게 하는게 좋구나... 이 정도만 생각하도록 하자.




1. 중복 코드

리팩토링을 꼭 해야 하는 상황은 중복 코드가 여러 곳에 있을 때이다. 이런 중복 코드는 하나로 통일을 해서 프로그램을 개선해야 한다. 


2. 장황한 메서드

최적의 상태로 장수하는 객체 프로그램을 보면 공통적으로 메서드의 길이가 짧다. 메서드의 길이가 길수록 이해하기 어렵다는 점은 많은 프로그래머들은 알고 있다. 이를 위해서 메서드를 과감하게 쪼개야 한다. 

메서드명은 기능 수행 방식이 아니라 목적(기능 자체)을 나타내는 이름으로 정해야 한다.


3. 방대한 클래스

기능이 지나치게 많은 클래스에는 보통 엄청난 수의 인스턴스 변수가 들어있다. 클래스에 인스턴스 변수가 많으면 중복 코드가 존재하기 마련이다. 클래스들을 추출하면 수많은 인스턴스 변수를 하나로 묶을 수 있다. 서로 연관된 변수를 골라서 클래스로 빼내면 된다. 


4. 과다한 매개변수

매개변수가 간결하다는 것은 장점이다. 매개변수가 길면 서로 일관성이 없어지거나 사용이 불편해지고, 더 많은 데이터가 필요해질 때마다 계속 수정해야 하기 때문에 그 매개변수들을 이해하기 힘들다. 웬만하면 객체를 넘기면 많은 문제가 해결 된다.


5. switch 문

객체지향 코드의 확연한 특징 중 하나는 switch ~ case 문이 비교적 적게 사용된다는 점이다. 

switch 문의 단점은 반드시 중복이 생긴다는 점이다. 같은 switch 문이 프로그램 곳곳에 있을 때가 많다. 그렇기 때문에 switch 문에 새 코드를 추가하려면 여기저기에 존재하는 switch 문을 전부 찾아서 수정해야 한다. 

이 문제를 해결하려면 객체지향 개념 중 하나인 다형성, 즉 재정의를 이용하는 것이다. 대부분의 switch 문은 고민할 필요없이 재정의로 바꿔야 한다. 


6. 인터페이스가 다른 대용 클래스

기능은 같은데 시그너처가 다른 메서드에는 메서드명 변경을 해야 한다. 클래스에 여전히 충분한 기능이 구현되어 있지 않기 때문에 대체로 이 방법만으로는 충분하지 않다. 프로토콜이 같아질 때까지 메서드 이동을 해서 기능을 해당 클래스로 옮겨야 한다. 단 코드를 너무 여러번 옮겨야 한다면 상위클래스 추출을 하면 된다.


7. 불필요한 주석

주석은 많이 사용할 수록 좋다. 하지만, 여기서부턴 이 기능, 여기서부턴 저 기능이라는 주석이 있다면 그것은 다른 메서드로 빼는 것이 좋다. 그 주석들은 불필요하다.


8. 변수명 수정

굳이 변수명을 수정하는 것이 왜 리팩토링이냐고 생각을 할 수도 있다. 하지만, 좋은 코드는 그것이 무슨 기능을 하는지 분명히 들어나야하는데, 코드의 기능을 분명히 드러내는 열쇠가 바로 직관적인 변수명이다.



9. 임시 변수 없애기

임시 변수로 인해 문제가 생길 수 있다. 임시 변수는 자체 루틴 안에서만 효력이 있다 보니, 점점 더 많은 임시변수를 사용하게 되어 코드가 복잡해지기 쉽다. 그렇기 때문에 임시 변수는 질의 메서드(Query Method)로 변경해주는 것이 좋다.



10. switch ~ case 문의 조건문 확인

만약 다른 객체의 속성을 switch 문의 인자로 사용하고 있다면 나쁜 방법이다. switch 문의 인자로는 타 객체 데이터를 사용하지 말고 자신의 데이터를 사용해야 한다.




728x90

'Basic Programming > Refactoring' 카테고리의 다른 글

Refactoring - 리팩토링 관련 문제들  (0) 2017.09.14
Refactoring - 리팩토링 이란 ?  (0) 2017.09.14
728x90

리팩토링을 진행하는 것도 좋지만, 리팩토링으로 인해 발생할 수 있는 문제점들 혹은 리팩토링이 어려운 상황에 대해 알아두는 것도 중요하다.




리팩토링으로 인해 발생할 수 있는 문제점들...



- 데이터 베이스

리팩토링에서 문제가 되는 부분 중 하나가 바로 데이터 베이스이다. 많은 비즈니스 어플리케이션은 바탕이 되는 데이터 베이스 스키마와 강력히 결합되어 있다. 이 때문에 데이터 베이스 수정이 어려워진다.


아무리 데이터 베이스 스키마와 객체 모델의 상호 의존성을 최소화하려고 시스템을 꼼꼼하게 계층 구조로 제작했더라도, 데이터 베이스 스키마를 수정하면 데이터도 이전해야 하는데, 이것은 시간도 오래 거릴 뿐 아니라 위험성도 높다.


이 문제를 해결하기 위해서 객체 모델과 데이터 베이스 모델 사이에 별도의 소프트웨어 계층을 두는 방법이 있다.

이렇게 하면 두 모델에 생긴 변경 사항을 따로 유지할 수 있어서 한 모델을 수정할 때 다른 모델은 수정할 필요 없이 그저 중개 계층만 수정하면 된다. 



- 인터페이스 변경

객체의 중대한 장점 중 하나는 인터페이스를 건드리지 않고 내부의 구현 코드를 수정할 수 있다는 점이다.

객체를 이용하는 부분을 수정하지 않고도 객체의 내부 구조를 안전하게 수정할 수 있지만, 인터페이스를 수정하면 어떤 문제가 발생할지 알 수 없으므로 인터페이스를 건드리지 않는다는 것은 큰 장점이다.


리팩토링에서 불안한 점은 상당수의 리팩토링이 인터페이스를 수정한다는 것이다.

함수명 변경도 그 자체가 인터페이스를 수정하는 작업이다.


특히, 이미 배포를 한 프로그램이고 내부 함수명을 수정했다면 그 인터페이스를 사용하는 측에서도 수정을 해야하므로 더 복잡하게 수정해야만 할 수도 있다.


위 문제를 해결하기 위해선 기존 인터페이스가 새 인터페이스를 호출하게 수정하면 간단하게 해결이 된다.





리팩토링을 하면 안되는 상황.



- 코드를 처음부터 새로 작성해야 할 때

코드가 돌아가지 않는다면 그건 완전히 새로 작성을 하라는 신호이다. 테스트만 하려다 코드가 버그 투성이라 안정화할 수 없음을 알게 될 경우가 바로 그 때이다. 


코드가 제대로 돌아가는 것이 가장 중요하다. 리팩토링은 그 이후의 일임을 반드시 명심하자.



- 납품일이 임박했을 때

납품일이 가까운 시점에 리팩토링을 해봤자 그로 인한 생산성은 납기가 지난 후에나 가시화될 테니 쓸데 없다.


하지만, 납품일이 임박한 경우가 아니면 시간이 없다는 핑계로 리팩토링을 미루면 안 된다.




728x90

'Basic Programming > Refactoring' 카테고리의 다른 글

Refactoring - 리팩토링을 해야 할 때  (0) 2017.09.14
Refactoring - 리팩토링 이란 ?  (0) 2017.09.14
728x90

리팩토링은 조금씩 조금씩 단계적으로 수정을 하고, 수정을 했으면 항상 신뢰도 높은 각종 테스트를 해야 한다.

그리고 각종 테스트는 반드시 자체 테스트가 되게 만들어서 테스트를 해서 시간을 단축하는게 좋다.




리팩토링이란?

1) (명사) 겉으로 드러나는 기능은 그대로 둔 채, 알아보기 쉽고 수정하기 간편하게 소프트웨어 내부를 수정하는 작업.

2) (동사) 리팩토링 기법을 연달아 적용해서 겉으로 드러나는 기능은 그대로 둔 채 소프트웨어 구조를 변경.



리팩토링과 최적화는 다른 작업이다.

리팩토링은 소프트웨어의 유지보수를 조금 더 쉽게할 수 있게 하고, 코드 가독성을 올리며 기능 추가를 더 쉽게 할 수 있게 하여 오히려 성능이 더 떨어질 수도 있다.

하지만 최적화 작업은 성능은 올라가더라도 코드의 가독성이 더 떨어질 때가 많다.



리팩토링에 대한 명언

리팩토링을 적용할 때에는 버그도 그대로 있어야 한다.



리팩토링을 하는 이유

1) 소프트웨어의 설계 개선. (중복 코드 제거)

2) 소프트웨어를 이해하기가 더 쉬워진다. (유지보수)

3) 버그를 찾기 쉬워진다.

4) 프로그래밍 속도가 빨라진다.



리팩토링을 하는 시기

한달에 하루 이런식으로 날잡고 하는게 아니라 개발과정에서 틈틈이 작업을 해야한다.


1) 같은 작업의 3진 아웃 때 

어떤 작업을 처음 할땐 그냥하고, 두 번째 작업할 땐 조금 찝찝하더라도 그냥 하고, 세 번째 하게 되면 그때 리펙토링을 실시하는 것이다.


2) 기능을 추가할 때

(1) 코드를 이해하기 쉽게 만들기 위해서 기능을 추가할 때 리팩토링을 해야한다.

(2) 설계가 지저분해서 어떤 기능을 추가하기 힘들 때에는 망설이지 말고 리팩토링을 진행해야 한다.


3) 버그를 수정할 때

코드의 기능을 파악하려다 이해하기 힘들다면 이해하기 쉽게 만들기 위해 리팩토링을 진행해야 한다.

리팩토링을 하고 나면 버그를 찾기 쉬워질 것이다.

버그 리포트가 입수되었을 때에도 리팩토링을 진행해야 한다. 왜냐하면 버그 리포트를 받을 때까지 버그가 있는 줄도 모를 정도면 그 코드가 엄청 지저분하다는 반증이기 때문이다.


4) 코드를 검수할 때

자신의 코드는 자기가 볼 땐 쉬울지 몰라도 다른 팀원이 볼 때에는 알아보기 힘들 수도 있다. 

리팩토링을 진행하면 다른 사람이 개발한 코드를 검수하기도 쉬워진다. 







728x90
728x90



위 화면에서 보는 것과 같이 기존 CXListCtrl에 여러가지 기능을 수정하고 추가하였습니다.

 

개발 환경

- Window XP : Intel X86 32bit

- Visual Studio 2005 : MFC 8.0 Unmanaged C++

 

에디터, 콤보, 날짜 컨트롤은 소스를 보시면 알겠지만 컨트롤에 대한 오브젝트가 클래스의 Static 멤버변수로 되어있습니다.

그리고 기존 CXListCtrl에서는 GDI를 사용하여 컨트롤을 직접 그리는 형태였습니다.

기능 확장성을 위해 지금처럼 컨트롤을 올리는 형태로 쓰는게 좋을 것 같습니다.

(아직 CheckBox와 Progress는 GDI로 직접 그리는 형태입니다.)

 

그리고 헤더컨트롤에 스킨 이미지를 적용했습니다. 현재는 헤더의 shadow 이미지가 한개지만 추후에는 마우스 over/out/click에 따라 이미지를 세분화하는게 좋겠습니다.

 

다음은 간단하게 XListCtrl에 추가한 기능들을 나열해 보았습니다.

 

1. 헤더 컨트롤

 - 헤더 높이 설정, 헤더 컬러 설정, 헤더 폰트 설정, 헤더 스킨 적용

 

2. 리스트 컨트롤

 - 마우스 이동시 라인별 Animate 효과

 - Underline 표시, Underline 컬러 설정

 - 아이템 높이 설정, 폰트 설정

 - Combobox, Editbox, Datebox Contorl 추가 및 기능 구현

 - 소트 함수 추가

 - 탭키로 다음 아이템 활성화 기능(Combox, Editbox, Datebox)

 

CXListCtrl에서 사용하는 클래스 목록은 다음과 같습니다.

 - CXHearderCtrl

 - CXComboBox

 - CXEditBox

 - CXSpinBox

 - CXDateBox

 

다음은 CXListCtrl의 외부에서 호출가능한 주요 설정 함수입니다.

 

1. void EnableFocusRect(BOOL bFocusRect=TRUE)
 - 아이템 선택시 포커스 컬러를 적용 유무 선택

 

2. void EnableResize(BOOL bResize=TRUE)
 - 컬럼 리사이징 가능 유무 선택

 

3. void SetNoItemMsg(CString strNoItemMsg)
 - 아이템이 없을 때 표시할 스트링 지정

 

3. void SetStatusColumn(int nSubItem)
 - 상태 컬럼을 지정 : 상태컬럼의 Rect은 다르게 조정되어 표시됨

 

4. void SetBgColor(COLORREF crBg)
 - 리스트 배경색 지정

 

5. void SetBgColorProgress(COLORREF crBg)
 - Progress 배경색 지정

 

6. void SetUnderLine(BOOL bUnderLine=TRUE)
 - 언더라인 유무 지정

 

7. void SetColorUnderLine(COLORREF crUnderLine)
 - 언더라인 컬러 지정

 

7. BOOL GetProgressColor(int nItem, int nSubItem, COLORREF &cf)
 - Progress 컬러 획득

 

8. void GetDrawColors(int nItem, int nSubItem, COLORREF& colorText, COLORREF& colorBkgnd)
 - 해당 서브아이템의 텍스트, 배경 컬러 획득

 

9. BOOL DeleteAllItems()
 - 모든 아이템 삭제

 

10. BOOL DeleteItem(int nItem);
 - 해당 아이템 삭제

 

11. int GetCheckbox(int nItem, int nSubItem)
 - 해당 서브아이템의 체크 박스 상태 획득

 

12. int GetColumns()
 - 컬럼수 획득

 

13. int GetCurSel()
 - 현재 선택된 첫번째 아이템 획득

 

14. DWORD GetItemData(int nItem)
 - 해당 아이템의 Data 획득

 

15. BOOL GetSubItemRect(int iItem, int iSubItem, int nArea, CRect& rect)
 - 해당 서브아이템의 Rect 획득

 

16. int InsertItem(int nItem, LPCTSTR lpszItem)
 - 아이템 추가: 아이템 텍스트 설정


17. int InsertItem(int nItem, LPCTSTR lpszItem, COLORREF crText, COLORREF crBackground)
 - 아이템 추가: 아이템 텍스트, 텍스트 컬러, 배경 컬러 설정

 

18. int InsertItem(const LVITEM* pItem);
 - 아이템 추가: LVIITEM 구조체 이용

 

19. BOOL SetComboBox(int nItem, int nSubItem, BOOL bEnableCombo, CStringArray *psa=NULL)
 - 해당 서브아이템 콤보박스 유무 설정 : 콤보박스 유무, String Array 설정

 

20. BOOL SetEditBox(...)
 - 해당 서브아이템 에디트박스 유무 설정 : 에디트박스 유무, 숫자입력일 경우 최소/최대값 지정, 문자열 최대길이 지정, 에디트 Style지정

 

21. BOOL SetDateBox(...);
 - 해당 서브아이템 Date박스 유무 설정 : Date박스 유무, Date Format, Date박스 Style 지정

 

22. BOOL SetProgress(int nItem, int nSubItem, BOOL bShowProgressText = TRUE, LPCTSTR lpszProgressText = NULL)
 - 해당 서브아이템을 Progress로 설정

 

23. BOOL SetCheckbox(int nItem, int nSubItem, int nCheckedState)
 - 해당 서브아이템 체크박스 상태 설정

 

24. BOOL SetItemData(int nItem, DWORD dwData)
 - 해당 아이템 Data 설정

 

25. BOOL SetItemImage(int nItem, int nSubItem, int nImage, BOOL bImageCenter=FALSE)
 - 해당 서브아이템 이미지 설정 : 이미지 인덱스, 이미지 센터 유무 설정

 

26. int GetItemImage(int nItem, int nSubItem)
 - 해당 서브아이템의 이미지 인덱스 획득

 

27. BOOL SetItemText(int nItem, int nSubItem, LPCTSTR lpszText)
 - 해당 서브아이템 텍스트 설정

 

28. BOOL SetItemText(int nItem, int nSubItem, LPCTSTR lpszText, COLORREF crText, COLORREF crBackground)
 - 해당 서브아이템 텍스트, 텍스트 컬러, 텍스트 배경 컬러 설정

 

29. BOOL SetItemTextColor(int nItem, int nSubItem, COLORREF crText, COLORREF crBackground)
 - 해당 서브아이템 텍스트 컬러, 텍스트 배경 컬러 설정

 

30. void UpdateDate(int nItem, int nSubItem, CTime time, COLORREF crText, COLORREF crBackground)
 - 해당 Date박스 업데이트 : 시간, 텍스트 컬러, 배경 컬러 설정

 

31. void UpdateProgress(int nItem, int nSubItem, int nPercent, COLORREF crText, COLORREF crBar, CString ProgressText=_T(""))
 - 해당 Progress 업데이트 : 퍼센트 값, 텍스트 컬러, Progress Bar 컬러 설정

 

32. virtual void Sort(int nSubItem, BOOL bSort)
 - 해당 서브아이템을 기준으로 정렬: bSort = TRUE:내림차순, FALSE:오름차순

 

33. void SetRowHeight(int nRowHeight)
 - 아이템 높이 설정

 

34. void SetTextFont(CFont *pTextFont)
 - 리스트 폰트 설정


다음은 CXListCtrl의 내부에서 호출되는 주요 함수 및 메시지입니다.

 

1. virtual BOOL OnNotify(WPARAM wParam, LPARAM lParam, LRESULT* pResult)
 - 컬럼 사이즈 조정 및 제어

 

2. void DrawProgress(...)
 - 해당 서브아이템의 Progress 그리기 : OnCustomDraw에서 호출됨
 - OnCustomDraw는 현재 OnPaint 함수속에 Default()를 통해서 호출됨, OnPaint 메시지를 핸들링 한다면 꼭 Default()함수를 호출 해야 함

 

3. void DrawCheckbox(...)
 - 해당 서브아이템의 체크 박스를 그림 : OnCustomDraw에서 호출됨
 - OnCustomDraw는 현재 OnPaint 함수속에 Default()를 통해서 호출됨, OnPaint 메시지를 핸들링 한다면 꼭 Default()함수를 호출 해야 함

 

4. void DrawText(...)
 - 해당 서브아이템의 텍스트 그리기 : OnCustomDraw에서 호출됨
 - OnCustomDraw는 현재 OnPaint 함수속에 Default()를 통해서 호출됨, OnPaint 메시지를 핸들링 한다면 꼭 Default()함수를 호출 해야 함

 

5. int DrawImage(int nItem, int nSubItem, CDC* pDC, COLORREF crText, COLORREF crBkgnd, CRect rect, XLISTCTRLDATA *pXLCD)
 - 해당 서브아이템의 이미지 그리기 : OnCustomDraw에서 호출됨
 - OnCustomDraw는 현재 OnPaint 함수속에 Default()를 통해서 호출됨, OnPaint 메시지를 핸들링 한다면 꼭 Default()함수를 호출 해야 함

 

6. void ShowComboBox(int nItem, int nSubItem)
 - 해당 서브아이템의 콤보박스 생성 및 표시 : OnLButtonDown에서 호출됨

 

7. void ShowEditBox(int nItem, int nSubItem)
 - 해당 서브아이템의 에디트박스 생성 및 표시 : OnLButtonDown에서 호출됨

 

8. void ShowDateBox(int nItem, int nSubItem)
 - 해당 서브아이템의 Date박스 생성 및 표시 : OnLButtonDown에서 호출됨
 
9. afx_msg void OnCustomDraw(NMHDR* pNMHDR, LRESULT* pResult)
 - 실제 아이템을 그려주는 함수 : 생성/표시되는 컨트롤들은 텍스트만 표시

 - 커스터마이징을 위한 메시지 함수

 

10. afx_msg void OnLButtonDown(UINT nFlags, CPoint point)
 - 실제 컨트롤을 생성/표시하는 함수

 

11. afx_msg void OnPaint()
 - 아이템이 없을 때 메시지를 표시

 - OnCustomDraw 메시지 핸들링을 위해 Default함수를 호출함
 - OnPaint 메시지를 추가하지 않았다면 OnCustonDraw 메시지는 내부적으로 호출됨

 

12. afx_msg BOOL OnEraseBkgnd(CDC* pDC)
 - 배경을 그림

 

13. afx_msg LRESULT OnMouseLeave(WPARAM wParam, LPARAM lParam)
 - 마우스 이동시 아이템 별 Animate 효과 처리를 위해 추가된 메시지

 

14. virtual BOOL PreTranslateMessage(MSG* pMsg);
 - 마우스 이동시 아이템 별 Animate 효과 처리를 위해 추가된 함수

 

15. afx_msg LRESULT OnEditChange( WPARAM wParam, LPARAM lParam )
 - 에디트 박스 종료 시 호출 됨 : 에디트 박스는 KillFocus될 때 종료됨
 - 변경된 값을 해당 서브아이템에 저장

 

16. afx_msg LRESULT OnDateChange( WPARAM wParam, LPARAM lParam )
 - Date 박스 종료 시 호출 됨 : Date 박스는 KillFocus될 때 종료됨
 - 변경된 값을 해당 서브아이템에 저장

 

17. afx_msg LRESULT OnComboChange( WPARAM wParam, LPARAM lParam )
 - Combo 박스 종료 시 호출 됨 : Combo 박스는 KillFocus될 때 종료됨
 - 변경된 값을 해당 서브아이템에 저장

 

18. void SetLButtonDown(int nStartItem, int nStartSubItem)
 - 특정 컨트롤에서 Tab키 이벤트에 의해 호출되는 함수로 다음 컨트롤로 활성화 시킴
 
19. static int CALLBACK CompareFunc(LPARAM lParam1, LPARAM lParam2, LPARAM lParamSort);
 - MFC 내부에서 호출되는 Sort를 위한 콜백 함수

 

 

MFC 클래스를 커스터마이징 하거나 분석하기 위해서는 C++의 가상함수와 각종 MFC 매크로에 대한 이해는

필수 입니다. MFC 프레임웍의 기본이 가상함수에 의한 설계이고 실제 그 설계자 본인들을 위해 CRuntimeClass 클래스 부터 각정 매크로를 선언, 정의하여 사용하도록 설계되었습니다.

 

우리가 이 클래스들을 커스터마이징하기 위해선 그 구조를 잘 이해하는 수 밖에 없습니다. 

물론 MFC 떠나 다른 프레임웍을 분석한다고 해도 똑같겠죠.

 

가상테이블과 런타임클래스의 무거움을 버리고 WTL/STL로만 개발할 수 있다면 좋겠습니다.;;

 

기타 의문점이나 개선사항 있으면 리플 부탁드립니다.


Update history

---------------------------------------------------------------------------------------------

- 2008.04.13_19:40 : Date Control 기능 보완, Date Format으로 한글이 가능하도록 Unicode 프로젝트로 설정




SkinListCtrl.zip




출처 : http://heart4u.co.kr/tblog/489

728x90

+ Recent posts