초기 버전 릴리즈
중복 코드 제거
SoEnty08까지 강좌가 의도한 기능은 모두 다 구현했다. 강좌 마지막 예제인 SoEnty09는 소스를 정리하고 버그도 아는
범위 내에서는 수정하여 릴리즈한다. 강좌를 위해 순서대로 예제를 만들다 보니 미리 적용하지 못한 부분도
있고 나중에서야 문제를 발견한 경우도 있다.
이럴 경우 앞으로 다시 돌아가 수정하는게 정상적이지만 사실 이 과정을 몇 번이나 거쳤으며 처음부터 다시 만들어
오는데 엄청난 시간이 걸린다. 차후에 강좌를 아예 다시 쓸 기회가 있다면 모르겠지만 현재는 마지막 소스를
직접 수정하는 것이 효율적이다.
먼저 중복 코드를 합친다. 클립보드에 문자열을 복사하는 위젯은 ClipText, ColorTable, EnumFont 등이 있는데 앞 둘은 직접 코드를 작성하다가 자꾸 반복되길레
EnumFont에만 함수를 만들었다. 함수가 나중에 추가되었으므로
앞에서 만든 두 위젯도 함수를 사용하도록 수정한다.
void CTextClip::ClipboardTextOnly()
{
....
lstrcpy(p2,
p);
GlobalUnlock(hmem);
CloseClipboard();
CopyClipboardText(p2);
free(p2);
clipCount++;
}
유니코드 텍스트를 읽은 후 다시 복사하는 코드를 삭제하고 CopyClipboardText
함수 호출로 바꾼다. 위쪽의 lstrcpyW 호출은
lstrcpy로 바꾸고 지역변수 len은 이제 불필요하여
삭제한다. p2가 바로 위에서 할당한 버퍼여서 복사 후 해제하는 코드는 누락하지 말아야 한다. ColorTableWin의 각 버튼 클릭시의 동작도 수정한다.
LRESULT CColorTableWin::OnCommand(WPARAM wParam,
LPARAM lParam)
{
....
case
CT_COPY1:
case
CT_COPY2:
case
CT_COPY3:
case
CT_COPY4:
hBtn
= GetDlgItem(win_hWnd, LOWORD(wParam));
GetWindowText(hBtn,
str, 128);
CopyClipboardText(str);
break;
버튼의 캡션을 조사하여 그대로 복사하면 된다. ID로부터 버튼의 핸들을
조사한 후 다시 캡션을 조사했는데 차일드 컨트롤이 WM_COMMAND 메시지를 보낼 때는 lParam이 윈도우 핸들이므로 다음과 같이 좀 더 짧게 쓸 수 있다. 이렇게
되면 지역 변수 hBtn은 필요 없다.
GetWindowText((HWND)lParam,
str, 128);
CopyClipboardText(str);
다음은 색상을 선택하는 오너드로우 콤보 박스의 코드를 합친다. 세
군데서 색상을 표시하는 오너드로우 콤보 박스를 사용하는데 사용하는 색상표가 다를 뿐 색상을 그리는 방법은 똑같다.
다음 함수를 Util 모듈에 추가한다.
void DrawOwnerItem(LPARAM lParam, sNamedColor
arColor[])
{
HBRUSH
bkBrush, Brush, oldBrush;
LPDRAWITEMSTRUCT
lpdis = (LPDRAWITEMSTRUCT)lParam;
//
선택 배경 그림
if
(lpdis->itemState & ODS_SELECTED) {
bkBrush
= CreateSolidBrush(RGB(0, 0, 255));
SetTextColor(lpdis->hDC,
RGB(255, 255, 255));
}
else {
bkBrush
= CreateSolidBrush(RGB(255, 255, 255));
SetTextColor(lpdis->hDC,
RGB(0, 0, 0));
}
FillRect(lpdis->hDC,
&lpdis->rcItem, bkBrush);
DeleteObject(bkBrush);
//
색상 그림
Brush
= CreateSolidBrush(arColor[lpdis->itemID].color);
oldBrush
= (HBRUSH)SelectObject(lpdis->hDC, Brush);
Rectangle(lpdis->hDC,
lpdis->rcItem.left + 2, lpdis->rcItem.top + 1,
lpdis->rcItem.left
+ 20, lpdis->rcItem.bottom - 1);
SetBkMode(lpdis->hDC,
TRANSPARENT);
TextOutSz(lpdis->hDC,
lpdis->rcItem.left + 25, lpdis->rcItem.top + 2,
arColor[lpdis->itemID].name);
SelectObject(lpdis->hDC,
oldBrush);
DeleteObject(Brush);
}
WM_DRAITEM의 lParam으로
그리기와 관련된 모든 작업 지시가 전달되므로 이 인수를 그대로 받고 표시할 색상 배열만 전달받으면 콤보 박스를 그릴 수 있다. 위젯 선택창의 콤보 박스 그리기 메시지에서 이 함수를 호출한다.
INT_PTR CALLBACK
CMainWindow::SelWidgetDlgProc(HWND hDlg, UINT iMessage, WPARAM wParam, LPARAM
lParam)
{
....
case
WM_DRAWITEM:
if
(wParam == IDC_CBBACKCOLOR) {
DrawOwnerItem(lParam,
arWidgetBackColor);
return
TRUE;
}
lParam을 그대로 넘겨주고 콤보 박스가 그릴 색상 배열을 두 번째
인수로 전달하면 나머지는 함수 안에서 자동으로 처리한다. 선택 항목인 경우 색상을 바꾸고 사각형에 색상을
그리고 그 옆에 색상의 이름도 같이 출력한다. 폰트는 따로 설정하지 않아도 대화상자의 폰트를 따르도록
되어 있어 이대로 두면 된다.
복잡한 구문이 함수 안으로 들어감으로써 호출부가 간단해졌다. 뿐만
아니라 직접 처리하기 위해 선언했던 브러시나 파라미터 변수도 불필요하다. 미사용 변수는 보이는 즉시
바로 삭제하는 것이 좋다. 이후에도 미사용 변수가 계속 생기는데 컴파일러의 메시지를 보고 삭제하자. 다음은 메인 옵션창을 수정한다.
INT_PTR CALLBACK CMainWindow::MainDlgProc(HWND
hDlg, UINT iMessage, WPARAM wParam, LPARAM lParam)
{
....
case
WM_DRAWITEM:
DrawOwnerItem(lParam,
arMainColor);
return
TRUE;
역시 함수 호출 한번이면 간단하게 끝난다. 메모 속성창에는 전경색, 배경색에 대해 오너 드로우 콤보 박스가 두 개나 있다. 조건에 따라
색상표가 달라질 뿐 그리는 방법은 같다.
INT_PTR CALLBACK MemoDlgProc(HWND hDlg, UINT
iMessage, WPARAM wParam, LPARAM lParam)
{
....
case
WM_DRAWITEM:
if
(wParam == IDC_CBFORE) {
DrawOwnerItem(lParam,
arMemoFore);
}
else {
DrawOwnerItem(lParam,
arMemoBack);
}
return
TRUE;
컨트롤에 따라 전달하는 색상표만 다를 뿐 lParam은 그대로 넘겨야
한다. 색상표를 선택하는 부분을 삼항 연산자로 바꾸면 한 줄로 압축할 수 있다.
DrawOwnerItem(lParam, wParam == IDC_CBFORE ?
arMemoFore : arMemoBack);
이 외에 EnumFont 티젯창에서도 오너드로우로 폰트를 그리는데
이 경우는 색상이 아니로 폰트여서 위 함수를 쓸 수 없다. 만약 커스텀 폰트 리스트 박스를 여러 곳에서
사용한다면 이 부분도 따로 함수로 빼는 것이 좋다.
세 곳의 코드 덩어리를 하나로 합쳐 대략 60줄 정도 줄어 들었다. 코드 줄 수가 줄어든 것보다 관리할 대상이 줄어들어 이후 색상 콤보 박스를 개선할 때 함수만 수정하면 된다. 이런 이유로 두 번 이상 중복되면 즉시 통합하는 것이 좋다. 이
프로젝트는 순서대로 실습하다 보니 중복 코드가 아직 많이 있는데 차차 더 합치기로 한다.
버그 수정
개발중에 CWindow의 윈도우 수명 관리에 심각한 문제가 있음을
인식했다. 위젯이나 티젯은 생명주기를 잘 관리하고 있지만 별도로 띄우는 창은 수명 관리가 제대로 되지
않는다. ColorTableWin, LCDTestWin, EnumFontWin 등 Win으로 끝나는 독립 윈도우들이 그렇다.
어떤 문제가 있는지 디버그 모드로 실행해 놓고 CWindowProc의
다음 위치에 중단점을 걸어 놓고 색상표 티젯을 클릭해 보자. 여기서 ColorTableWin
객체를 생성하며 새로 만든 윈도우를 맵에 등록한다.
등록 시점에 맵의 크기를 조사해 보면 23이다. 그 전에는 22였는데 방금 23이
된 것이다. 계속 실행한 후 색상표를 닫고 다시 띄워 보면 이번에는 24가
된다. 실행할 때마다 계속 맵의 윈도우수가 늘어난다. 이는
색상표창이 등록만 할 뿐 해제를 하지 않는다는 뜻이며 맵에 불필요한 쓰레기가 계속 쌓인다.
객체가 해제되지 않으니 메모리는 계속 세고 있다. 진단창을 열어 놓고
색상표를 계속 열어 보면 사용 메모리가 완만하게 늘어나는 것을 확인할 수 있는데 그나마 색상표가 메모리를 많이 쓰지 않기 때문에 치명적이지는 않다.
약간의 메모리 누출이 있어도 당장은 당장은 큰 문제를 느낄 수 없다. 새로
만든 윈도우는 핸들이 이전과는 다르기 때문에 무효한 객체를 찾지는 않기 때문이다. 그러나 정말 그렇다고
보장할 수는 없다. 우연히 과거 핸들과 같은 핸들이 생성될 수도 있으며 이때는 엉뚱한 다른 객체를 참조하기
때문이다.
색상표를 종료하기 전에 객체도 지우고 맵에서도 제거해야 한다. OnDestroy에서
객체를 삭제하는 처리가 필요하다. 마지막에 자살하는 코드를 작성해 보자. 객체가 스스로를 지우는 것은 문법적으로 합법이며 그 자체는 문제가 없다. 파괴자에서 Dispose를
호출하여 객체 맵에서 자신을 제거한다.
LRESULT CColorTableWin::OnDestroy(WPARAM wParam,
LPARAM lParam)
{
....
delete
this;
return
0;
}
그러나 이 코드를 실행하면 색상표가 닫힐 때 다운되어 버린다. 왜냐하면
WM_DESTROY가 윈도우 생애의 끝이 아니며 이후에도 WM_NCDESTROY
메시지가 더 날라가기 때문이다. 윈도우 파괴 후 타이틀 바나 경계선 등의 리소스도 정리해야
하는데 이때 객체 자체가 사라져 버리면 더 정리할 주체가 없다.
CWindowProc은 맵에 없는 객체가 메시지를 보내면 새로 등록하는데
이때 lParam으로 객체 포인터가 전달되지 않아 캐스팅하다가 다운된다. 객체를 만든 주체가 직접 파괴하면 이런 문제가 없다. 과연 그런지
티젯의 OnClick에 다음 코드를 작성하여 만든 직후에 바로 삭제해 보자.
void CColorTable::OnClick() {
CColorTableWin*
pWin = new CColorTableWin();
pWin->Create(NULL);
DestroyWindow(pWin->win_hWnd);
delete
pWin;
Trace(L"맵
크기 = %d", CWindow::pWinMap->size());
}
윈도우를 파괴한 후에 객체를 지운다. DestroyWindow 함수
호출중에 파괴와 관련된 일련의 메시지가 모두 날라가며 이 함수가 리턴했을 때는 더 처리할 메시지가 없다. 이
상태에서 객체를 지우면 Dispose도 정상적으로 호출되고 객체나 맵 크기나 변화없이 일정하게 유지할
수 있다. Trace를
찍어 보면 과연 그렇다.
맵 크기 = 22
맵 크기 = 22
맵 크기 = 22
문제는 DestroyWindow를 코드에서 직접 호출하는게 아니라
사용자가 호출한다는 점이다. 타이틀 바의 X 버튼을 누르면
이때 윈도우를 파괴하며 객체는 OnDestroy를 통해 파괴된다는 사실만 통보받을 뿐, 완전히 파괴된 시점을 잡을 수가 없다. 윈도우가 파괴될 때 어떤
메시지가 날라오는지 찍어 보자.
CColorTableWin* pCt;
void CColorTable::OnClick() {
CColorTableWin*
pWin = new CColorTableWin();
pCt
= pWin;
pWin->Create(NULL);
Trace(L"파괴전");
DestroyWindow(pWin->win_hWnd);
Trace(L"파괴후");
delete
pWin;
Trace(L"제거후");
Trace(L"맵
크기 = %d", CWindow::pWinMap->size());
}
임시 전역 변수에 색상표 객체의 포인터를 대입해 놓는다. CWindowProc에서는
이 객체가 받는 모든 메시지를 덤프한다. 다른 윈도우와 공유하는 함수여서 중단점으로는 특정 객체의 메시지만
살펴 보기 어렵고 Trace를 찍어 봐야 한다.
extern CColorTableWin* pCt;
LRESULT CALLBACK CWindow::CWindowProc(HWND hWnd,
UINT iMessage, WPARAM wParam, LPARAM lParam)
{
CWindow*
pWin = nullptr;
if
(pWinMap->find(hWnd) != pWinMap->end()) {
pWin
= (*pWinMap)[hWnd];
}
if
(pCt != nullptr && hWnd == pCt->win_hWnd) {
Trace(L"메시지 = %x", iMessage);
}
메시지 상수를 정의하는 WinUser.h에 메시지 번호가 16진수로 정의되어 있어 메시지 번호도 16진수로 출력했다. 파괴시 전달되는 메시지는 다음과 같다.
메시지 = 5
메시지 = 7f
파괴전
메시지 = 90 //
비문서화
메시지 = 46 //
WM_WINDOWPOSCHANGING
메시지 = 47 //
WM_WINDOWPOSCHANGED
메시지 = 86 //
WM_NCACTIVATE
메시지 = 6 //
WM_ACTIVATE
메시지 = 8 //
WM_KILLFOCUS
메시지 = 281 //
WM_IME_SETCONTEXT
메시지 = 282 //
WM_IME_NOTIFY
메시지 = 2 //
WM_DESTROY
메시지 = 82 //
WM_NCDESTROY
파괴후
제거후
맵 크기 = 22
파괴 전에 위치 변수, 활성화, 포커스
변화 등 여러 가지 메시지가 날라온다. 그리고 파괴한다는 WM_DESTROY
메시지가 날라오며 마지막으로 WM_NCDSESTROY가 날라온다. 이 메시지를 받았을 때 객체를 지우고 맵에서도 제거하면 된다.
그러나 모든 윈도우를 다 이 방식으로 정리할 필요는 없다. 위젯, 티젯은 이미 잘 관리하고 있고 윈도우 스타일에 따라서는 WM_NCDESTROY
이후에도 더 처리할 메시지가 있을 수도 있다. 사용자가 직접 닫는 창에 한해서만 이 정책을
적용하면 된다. CWindow에 멤버를 하나 더 추가한다.
class CWindow
{
public:
....
bool
delegateDispose = false;
이 멤버가 true이면 메시지 핸들러에서 알아서 객체를 정리해 준다. 정리 작업을 최상위 클래스에게 위임한다는 뜻이다. OnMessage의
마지막에 정리 코드를 작성한다.
LRESULT CWindow::OnMessage(UINT iMessage, WPARAM wParam, LPARAM
lParam) {
....
LRESULT ret
= DefWindowProc(win_hWnd, iMessage, wParam, lParam);
if
(delegateDispose && iMessage == WM_NCDESTROY) {
delete
this;
}
return ret;
}
위임한 윈도우가 WM_NCDESTROY를 받았을 때 자신을 삭제한다. 색상표는 자신을 생성한 직후에 정리를 위임한 후 생성한다.
void CColorTable::OnClick() {
CColorTableWin*
pWin = new CColorTableWin();
pWin->delegateDispose
= true;
pWin->Create(NULL);
}
이 작전이 과연 잘 통하는지 CWindowProc에 Trace 호출을 추가해 보자. 이 로그는 앞으로도 계속 관찰해야 하므로 아예 포함시켜 두도록
한다.
LRESULT CALLBACK CWindow::CWindowProc(HWND hWnd,
UINT iMessage, WPARAM wParam, LPARAM lParam)
{
if
(pWin == nullptr) {
....
(*pWinMap)[hWnd]
= pWin;
pWin->win_hWnd
= hWnd;
Trace(L"%d
윈도우 등록. 맵 크기 = %d", hWnd,
pWinMap->size());
여기까지 작성한 후 색상표를 열어다 닫았다 반복해 보면 잘 정리되는 것을 알 수 있다. 그러나 SizeMeter, Tetris, EnumFont 등은 아직
이 정책을 적용하지 않아 윈도우 수가 계속 늘어난다. 각 티젯의 OnClick에도
동일한 코드를 작성해 정리를 위임하자.
Tidget.cpp에서 OnClick으로
검색해서 윈도우를 생성하는 문장 바로 다음에 위임문을 작성해 넣으면 된다. MoveCursor나 TextClip 등 별도의 창을 띄우지 않는 티젯은 그럴 필요가 없다.
void CLCDTest::OnClick() {
CLCDTestWin*
pWin = new CLCDTestWin();
pWin->delegateDispose
= true;
pWin->Create(NULL);
}
....
void COneImage::OnClick()
{
if (nowImage
!= NULL) {
//
뷰어를 연다.
if
(pViewer == NULL) {
pViewer
= new CImageViewer();
pViewer->delegateDispose
= true;
....
위젯 중에는 유일하게 ImageSlide가 창을 띄우는데 여기에도
동일한 처리가 필요하다.
LRESULT CImageSlide::OnLButtonDown(WPARAM wParam, LPARAM lParam)
{
...
CImageViewer*
pImgViewer;
pImgViewer
= new CImageViewer();
pImgViewer->delegateDispose
= true;
여기까지 처리한 후 객체 맵이 잘 정리되는 것을 확인했는데 또 다른 문제가 발생했다. 테트리스 창을 닫는 중에 다운되는 문제가 발견되었다. 똑같은 창인데
혼자 죽는다는 것은 테트리스 자체에 버그가 있다는 얘기다. 조사해 보니 board 배열이 1000 * 1000 크기로 4M인데 멤버 크기가 이렇게 크면 동적 할당시에도 문제가 발생한다.
unsigned char board[405][205];
요렇게 다이어트를 좀 했다. 최대 크기가 400 * 200이지만 벽부분까지 고려해야 하므로 소심하게 조금 더 늘렸다.
80K로 대략 40배 줄인 셈이다. 버그를 잡다
보면 다른 버그가 또 보이는 경우가 있는데 보이는 족족 잡아야 한다. 이상으로 창 정리 문제를 일단락했는데
이 방법도 완벽한 것은 아니다. 또 다른 문제가 더 발생한다면 다음 작전을 고려중이다.
- 모든 창의 닫기 명령을 직접 처리한다. WM_SYSCOMMAND 메시지에서 SC_CLOSE 명령을 직접
처리하면 DestroyWindow와 Dipose를 호출할
수 있다. 그러나 모든 윈도우가 이 처리를 일일이 하기는 번거롭다.
- 파괴할 창의 포인터를 벡터에 저장해 두고 메인이 주기적으로 정리한다. 자바 가상 머신이나 C#의 프레임워크가 하는 가비지 컬렉션을 따라하는
것인데 의외로 효율적이고 편하다.
지금은 이 정도까지 고려할 정도는 아니어서 비교적 간단한 방법으로 해결했다. 완벽한
해결책은 아니지만 원인을 분명히 알고 취한 조치이므로 다른 문제가 더 발생해도 대처 가능하다.
또 다른 버그는 메인창의 폭을 조정할 때 트레이의 두께가 바로 갱신되지 않고 한박자 늦다가 마우스를 놓으면 엉뚱한
크기로 설정되는 것이다. 두 줄로 나열했다가 폭을 줄여 세줄이 되면 두줄, 세줄 사이를 왔다 갔다 하다가 결국 두줄에서 멈추어 버리며 아래쪽이 잘린다.
스파이로 창을 찍어 보면 트레이의 높이는 88로 맞지만 전체 윈도우의
높이가 1030이어야 하는데 1002로 28픽셀 더 적게 설정된다. 28은 티젯과 갭의 합이며 두 줄일 때의
높이로 복원되는 문제가 있다. 창 크기를 찍어 보면 트레이가 잘못된 것이 아니라 메인의 크기가 잘못된
것임을 알 수 있다. 이럴 때 쓰자고 스파이를 만들어 놓은 것이다. 어디서 계산을 잘못하고 있는지 여기 저기에 Trace를 삽입해 본다.
void CTrayWindow::UpdateTrayThick(int widgetThick)
Trace(L"widgetThick
= %d, perLine = %d, trayLine = %d, trayThick = %d",
widgetThick,
perLine, trayLine, trayThick);
void CMainWindow::Relayout()
Trace(L"크기
조정 %d * %d", clientWidth, clientHeight);
LRESULT CMainWindow::OnPaint(WPARAM wParam, LPARAM
lParam)
Trace(L"OnPaint,
%d * %d", crt.right, crt.bottom);
LRESULT CMainWindow::OnSize(WPARAM wParam, LPARAM
lParam)
Trace(L"OnSize,
%d * %d", crt.right, crt.bottom);
오른쪽 경계선을 드래그하여 크기를 조정하다가 2줄에서 3줄로 늘어나는 시점에 크기 조정을 완료했다. Trace 결과는 다음과
같다.
widgetThick = 137, perLine = 4, trayLine = 3, trayThick = 88
크기
조정 145 * 1030 //
Relayout에서는 크기 제대로 설저하고 있음
OnSize, 145 * 1030
Paint, 145 * 1030
OnSize, 144 * 1002 //
중간 중간에 불필요한 OnSize가 날라오며 수치가 틀렸음.
widgetThick = 135, perLine = 4, trayLine = 3,
trayThick = 88
크기 조정 143 * 1030
OnSize, 143 * 1030
Paint, 143 * 1030 //
여기까지 경계선 드래그 중
OnSize, 143 * 1002 //
마우스 버튼을 놓을 때 이전 크기로 재 설정되어 버림.
Paint, 143 * 1002
코드에서 직접 처리하지 않았는데 OnSize가 이전 크기로 강제로
날라오며 마우스 버튼을 놓을 때도 이전 크기로 복원되어 버린다. 어떤 메시지가 날라오는지 확인해 봐야
하는데 내가 만든 스파이는 메시지 염탐 기능은 아직 없다. 진짜 스파이로 메시지를 찍어 보았다.
517번 메시지에서 메인의 높이가 1030이었는데
마우스 버튼을 놓으면 캡처 변화, 윈도우 위치 변화 등의 메시지를 거치며 1002짜리 OnSize가 한 번 더 날라온다. 윈도우 스타일이나 메시지 프로시저 등 여러 가지 원인이 있을 수 있다. SetWindowPos
함수의 플래그가 문제인가 싶어 MoveWindow로 바꾸어 보아도 증상은 똑같다.
RECT wrt;
GetWindowRect(win_hWnd, &wrt);
MoveWindow(win_hWnd, wrt.left, wrt.top, clientWidth,
clientHeight, TRUE);
이건 운영체제가 보내주는 거라 뭔가 합당한 이유가 있을 것으로 생각되며 약 한시간 정도 살펴 보다가 시간 부족으로
해결을 포기했다. 이런 식으로 해결하지 못한 채 알고만 있는 버그를 노운 버그(Known Bug)라고 하는데 원칙상 잡아야 하지만 여러 가지 사정으로 그러지 못하는 경우가 있다. 좀 보기 싫을 뿐 치명적이지는 않으며 위젯 사이를 살짝 한번 더 드래그하면 문제가 해결되기는 한다.
내일 당장 출근해야 하는 상황에서 이 버그만 잡고 있을 수가 없어 일단 남겨 두고 차후에 잡기로 한다. Trace문은 아직 삭제하지 않고 문제 해결시까지 남겨 두기로 한다. 나도
이런 상황이 싫지만 어쩔 수 없다. 이 외에도 숱한 버그가 있었는데 간단한 것은 모두 앞 단계에서 다
수정해 두었다.
젯 선택 및 순서
위젯, 티젯을 신나게 늘려갈 때는 일단 만들어 놓고 보는지라 설명이나
이름을 세심하게 붙이지 못한다. 그냥 대충 끄적거려 놓고 나중에 생각해 보자는 작전인데 지금이 바로
그 나중이다. 릴리즈 하기 전에 설명을 좀 더 상세하고 친절하게 붙일 필요가 있어 일괄 편집했다.
// 이 프로그램이
보유한 위젯, 티젯 목록. 이 중 사용자가 선택한 것만 사용한다.
SWidgetInfo arWidgetInfo[] = {
{L"시계", L"현재 시간을 보여 준다. 디지털/아날로그 페이스를 선택할 수 있으며 초단위 표시, 24시간제, 두 자리 표기 등의 옵션이 있다.",
L"Clock",
true, 80, 120, GetColorFromName(L"PapayaWhip")},
{L"진법변환기", L"2진수, 10진수, 16진수를 자동 변환한다. 세 값 하나를 입력하면 나머지 진법을 즉시 변환한다.",
L"Radix",
true, 50, 120, GetColorFromName(L"Violet")},
{L"CPU
사용량", L"CPU 점유율을
총 60회의 그래프로 표시한다. 조사주기를 선택할 수 있고
최대 점유율에 따라 Y축 범위를 자동 결정한다.",
L"CpuUsage",
true, 100, 140, GetColorFromName(L"PaleTurquoise")},
{L"메모리 사용량", L"메모리 총 설치량, 사용량, 사용 비율을 표시하며 주기적으로 갱신한다. ",
L"MemUsage",
true, 50, 120, GetColorFromName(L"LightBlue")},
{L"배터리", L"배터리 남은 용량과 시간, 충전 상태를 조사하여 막대 그래프로 충전 비율을 표시한다.",
L"Battery",
true, 50, 120, GetColorFromName(L"LightSkyBlue")},
{L"디스크 사용량", L"하드, SSD 등의 스토리지 용량과 사용량을 표시한다. 이동식, 네트워크 드라이브도 같이 표시할 수 있으며 최대 용량 스토리지에 대한 상대적인 비율로 표시한다.",
L"DiskUsage",
true, 50, 120, GetColorFromName(L"Wheat")},
{L"계산기", L"다항식을 계산한다. 사칙 연산과 누승(^), 괄호 우선 순위 등을 지원한다. 이전 계산식을 콤보 박스에서 다시 불러올 수 있고 계산 결과를 클립보드로 복사한다. ",
L"Calc",
true, 50, 120, GetColorFromName(L"Pink")},
{L"음악 재생기", L"MP3 음악을 재생한다. 탐색기에서 파일을 드래그하여 음악을 추가하며 상단의 그룹탭을 사용하여 4개의
그룹에 음악 목록을 각각 관리한다. 프로그래스 바를 드래그하여 임의 위치로 이동하며 랜덤 재생 옵션을
지원한다. Pause키는 전역 재생/정지 단축키이다.",
L"MusicPlayer",
true, 150, 120, GetColorFromName(L"Gainsboro")},
{L"이미지 슬라이더", L"이미지 목록을 주기적으로
교체하며 보여 준다. 파일을 드래그하여 목록에 추가하며 마우스 오른쪽 버튼을 눌러 나타나는 팝업창에서
순서 및 시간을 선택한다.",
L"ImageSlide",
true, 100, 120, GetColorFromName(L"DarkGray")},
{L"메모", L"텍스트 형식의 간단한 메모를
기록 및 편집한다. 위젯 화면에서 직접 편집 가능하다. 우상단의
확대 버튼을 클릭하여 포스트잇 형식의 별도의 메모창으로 열어 편집할 수 있으며 각 메모의 색상, 글꼴
등을 선택할 수 있다.",
L"Memo",
true, 150, 150, GetColorFromName(L"Ivory")},
{L"날짜 세기", L"특정 날짜 이후 경과
시간 또는 특정 날짜까지 남은 시간을 보여 줍니다. 예를 들어 금연
12일째, 제대 625일 전의 시간 정보를 보여
준다. 일, 시, 분까지
상세하게 볼 수 있다. ",
L"Dday",
true, 80, 120, GetColorFromName(L"SpringGreen")},
{L"",
L"", L"", false, 0, 0, RGB(0, 0, 0)},
};
STidgetInfo arTidgetInfo[] = {
{L"LCD
테스트", L"LCD 액정을
점검합니다. 색상, 모니터를 단축키로 변경하며 애니메이션을
통해 잔상 검사를 수행한다. Esc키로 종료한다.",
L"LCDTest",
false},
{L"클립보드 변환기", L"클립보드에 텍스트
포맷만 남기는 Ctrl + Shift + C 단축키를 제공한다. 서식없이
텍스트만 복사할 때 사용하며 티젯을 클릭하여 동작 여부를 토글한다.",
L"TextClip",
false},
{L"색상 테이블", L"표준 색상표를 보여주고
색상값을 복사한다. 세가지 형식의 색상표를 지원하며 두 가지 색상을 차례대로 선택하여 비교한다.",
L"ColorTable",
false},
{L"커서 이동", L"주기적으로 커서를 이동하여
화면 보호기 동작을 방지한다. 장기간의 작업을 수행할 때 컴퓨터를 계속 동작 상태로 유지한다.",
L"MoveCursor",
false},
{L"윈도우 크기 측정", L"표준 모니터 크기의
면적을 실제 윈도우로 확인한다. 창 크기를 바꾸어 임의 크기를 픽셀 단위로 확인한다.",
L"SizeMeter",
false},
{L"테트리스", L"심심풀이 테트리스 게임이며
다양한 크기를 지원한다. ",
L"Tetris",
false},
{L"참조 이미지", L"단 하나의 이미지를
원하는 곳에 원하는 크기로 신속하게 열어 확인한다. 등록해 놓은 이미지와 위치, 크기를 유지하여 클릭 동작으로 항상 같은 위치에서 이미지를 확인할 수 있다.",
L"OneImage",
true},
{L"폰트 열거", L"설치되어 있는 폰트의
목록을 보고 모양을 확인하며 특성을 조사한다. 폰트 생성 코드를 작성하여 복사한다.",
L"EnumFont",
true},
{L"스파이", L"커서 위치의 윈도우 속성과
윈도우 계층 조사한다. 1초 주기로 동작하며 스파이창 안으로 들어오면 조사를 일시 중지한다.",
L"Spy",
true},
{L"",
L"", L"", false},
};
설명이 반말로 되어 있는 것은 평가판이라 그렇다. 프로페셔널 버전을
구매하면 좀 더 공손한 존재말로 바뀔 예정이되 언제 유료 버전을 발표할지는 알 수 없다. 설명을 이렇게
편집해 놓고 대화상자를 띄워 보니 아래쪽에 한줄만 보인다. Auto Hscroll 스타일이 적용되어
있어서 그런데 이 스타일을 꺼도 다 안 보이기는 마찬가지이다.
설명 에디트 박스를 좀 더 넓고 높게 넉넉하게 영역을 할당했다. 이런
버그는 테스트를 대충 했다는 뜻이며 쪽팔린데 릴리즈 전에라도 수정한 것이 참 다행이다. 차후 이미지까지 넣어 더 상세한 설명을 넣어 매뉴얼을 대신할 계획이다.
다음은 기본 젯을 선택한다. 만드는 족족 일단 동작을 확인해야 하니
모든 젯을 다 기본에 포함시켜 두었는데 누구나 다 그렇게 쓰는 것은 아니다. 자주 사용하고 누구에게나
필요할 거 같은 몇 가지 젯만 꺼내 놓고 나머지는 사용자가 필요할 때 선택하는 것이 바람직하다. 또
초기 순서도 의미가 있는데 비슷한 것끼리 모아 두는 것이 좋다. OnCreate의 디폴트 세팅을 다음과
같이 조정한다.
vertThick =
setting.get(L"main", L"vertThick", 220);
horzThick =
setting.get(L"main", L"horzThick", 160);
....
if
(widget_num == 0) {
//
위젯 배열 초기화
pWidget
= CWidget::CreateDefaultObject(L"Clock");
arWidget.push_back(pWidget);
pWidget
= CWidget::CreateDefaultObject(L"CpuUsage");
arWidget.push_back(pWidget);
pWidget
= CWidget::CreateDefaultObject(L"MemUsage");
arWidget.push_back(pWidget);
pWidget
= CWidget::CreateDefaultObject(L"Battery");
pWidget->span
= true;
arWidget.push_back(pWidget);
pWidget
= CWidget::CreateDefaultObject(L"Calc"); arWidget.push_back(pWidget);
pWidget
= CWidget::CreateDefaultObject(L"MusicPlayer"); arWidget.push_back(pWidget);
pWidget
= CWidget::CreateDefaultObject(L"ImageSlide");
arWidget.push_back(pWidget);
//
티젯 배열 초기화
pTidget
= CTidget::CreateDefaultObject(L"LCDTest");
arTidget.push_back(pTidget);
pTidget
= CTidget::CreateDefaultObject(L"ColorTable"); arTidget.push_back(pTidget);
pTidget
= CTidget::CreateDefaultObject(L"TextClip");
arTidget.push_back(pTidget);
pTidget
= CTidget::CreateDefaultObject(L"MoveCursor");
arTidget.push_back(pTidget);
pTidget
= CTidget::CreateDefaultObject(L"OneImage"); arTidget.push_back(pTidget);
pTidget
= CTidget::CreateDefaultObject(L"EnumFont");
arTidget.push_back(pTidget);
pTidget
= CTidget::CreateDefaultObject(L"Spy"); arTidget.push_back(pTidget);
진법 변환기, 디스크 용량, 메모, Dday 위젯은 일단 숨겼다. 개발자가 주로 사용하는 기능이거나
크게 관심을 갖지 않는 정보 또는 다른 대체 프로그램이 있는 경우이다. 메모리와 배터리는 셀 병합한
상태로 릴리즈한다. 티젯은 자리를 많이 차지하지 않으므로 대부분 표시하되 테스트리와 SizeMeter 두 개만 숨긴다.
물론 초기 설정상 숨기는 것 뿐이며 사용자가 언제든지 다시 꺼내 사용할 수 있다. 그러나 개발자 입장에서 애써 만들어 놨는데 처음에 안 보이면 기능이 존재 자체가 보이지 않아 좀 억울한 면이
있다. 그렇다고 너무 다 끄집어 내 놓으면 지저분해 지는 감이 있으니 적당한 수준에서 자재해야 한다.
위젯 목록과 함께 초기 폭과 높이도 조정했다. 원래는 200, 120이었는데 수직으로 나열시 메모리와 배터리를 병합 표시히기에는 좁아 20픽셀 더 늘렸다. 수평도 120은
너무 낮은 감이 있어 높이를 약간 높였다. 디폴트 배치를 보려면 INI
파일을 지운 후 다시 시작해야 한다.
각 위젯의 디폴트 높이나 배경색상 등도 조정할 필요가 있지만 지금 배치 상태로도 그리 나쁜 것 같지는 않다. 당분간 이 구성으로 릴리즈하기로 한다.
배포 방법
여기까지 개발한 버전이 교육용 프로젝트 이름으로는 SoEnty09이지만
공식 버전은 0.5이다. 초기에 비해 소스도 많이 정리되었고
기능도 풍부해졌지만 이제 겨우 1.0까지 절반 정도 왔다는 얘기이다.
0.5 버전의 총 소스 줄수는 9607줄이며 릴리즈 실행 파일의 크기는 350K이다.
20일전에 릴리즈한 0.4 버전에
비해 소스는 1000줄 늘었고 실행 파일은 55K 늘었다. 아직 만 줄이 안되는데 기능에 비해서 소스는 대단히 압축적인 셈이다. 이제
이 파일을 릴리즈해서 웹에 발표하면 된다. 단독 실행 파일이어서 구성 파일 없이 exe만 올리면 된다. 그러나 아주 심각한 문제가 하나 더 있다.
SoEnty.exe를 압축하여 웹에 올린 후 다운로드 받아 압축을
푼다. 다운로드 직후부터 디펜더가 바이러스로 인식하여 보안 경고창을 띄우며 실제 바이러스가 있다고 보고한다. 이전 버전에는 파일을 아예 자동 삭제해 버리기도 했는데 0.5 버전은
다행히 그러지는 않는다. 강제 실행하면 스마트 스크린이 게시자를 알 수 없다는 경고를 띄운다.
이 경고를 무시하고 강제로 실행하면 실행은 가능하다. 그러나 매번
실행할 때마다 다운로드 받은거니 위험하다는 경고가 뜬다. 내가 나쁜 짓을 할 사람은 아니지만 사이닝을
하지 않은 출처 불명의 프로그램을 경고하는 동작은 합당하다. 그러나 비주얼 스튜디오로 만든 프로그램을
바이러스로 진단하는 것은 문제가 있다.
똑같은 문제를 겪은 사람이 분명 있을 것이므로 구글링을 해 봤다. 비주얼
스튜디오 2019로 Hello World만 만들어도 Trojan:Win32/Fuery.C!cl 로
진단하고 실행을 금지한다. 같은 회사에서 만든 프로그램인데 설마 이 정도 테스트도 안하고 발표를 했을까
싶은데 마이크로소프트의 공식적인 답변은 다음과 같다.
바이러스로 오인 받는게 정상적이니 대상 폴더를 예외 설정하면 컴파일할 수 있다는 것이다. 이걸 과연 답변이라고 올린 것일까 싶다. 컴파일이 궁극의 목적이
아니라 배포를 해야 사용자가 쓸 수 있다. 그럼 모든 사용자가 예외 설정을 해야 비주얼 스튜디오로 만든
프로그램을 실행할 수 있는가?
프로젝트의 옵션을 조정하라거나 출처를 밝히는 사이닝을 해라는 답변을
기대했는데 그렇지 못하다. 실시간 검사를 잠시 끄거나 아예 디펜더를 사용 안함으로 설정하라는 답변도
있고 SDL 옵션을 켜야 한다는 답변도 있는데 다 정확한 해결 방법이 아니다. 차라리 디펜더의 버그이며 해결중이라는 얘기가 더 현실적이다.
혹시 비주얼 스튜디오가 정품이 아닌 교육용 커뮤니티 버전이어서 사이닝 기능이 아예 없거나 학습을 목적으로 한
코딩만 할 수 있을 뿐 배포 가능한 프로그램은 릴리즈 못한다면 이해할 수 있다. 좀 야속하지만 원래
커뮤니티 버전이 연구를 위해 공개한 것이므로 그럴 수는 있다. 배포는 아마도 사이닝의 문제인 것 같은데
출처를 밝히지 않았으니 의심을 받는 것이 당연하다.
putty.exe 같은 정상적인 프로그램도 웹을 경유하여 다운로드
받으니 위험하다는 경고가 뜬다. 혹시나 버전상의 문제인가 싶어 10년이나
더 지난 비주얼 스튜디오 2010을 설치하여 Hello World를
만든 후 웹을 통해 배포해 보니 이 또한 똑같은 문제가 발생했다. 바이러스나 랜섬웨어가 창궐하는 세상이니
출처가 분명치 않은 실행 파일을 배포하지 못하도록 막는 것도 이해는 간다.
결국은 사이닝을 확실히 하여 보안상의 문제를 해결해서 배포하는 수밖에 없을 거 같다. 아직 1.0도 릴리즈하지 못했고 지금은 연구 버전이므로 당분간은
소스와 실행 파일을 분리해서 배포하는 방법을 사용해야 할 것 같다.
이후의 작업 목록
SoEnty 제작 강좌는 여기서 일단락 짓지만 SoEnty 프로젝트 자체는 아직도 한참 개발중이다. 앞으로 더 추가할
위젯이나 티젯도 많고 프로그램 전반적으로 개선할 목록도 많다. 언제 할지는 모르겠지만 다음 작업을 일단
정리는 해 두고 시간이 나는대로 하나씩 순서대로 작업할 것인다.
추가할 위젯
론처 - 타스크바의 빠른 실행과 같은 론처 작성. 16, 32의 아이콘으로 등록하고 클릭시 실행한다.
낙서 - 바탕 화면의 임의 위치에 도형이나 곡선 등을 그려 동료와
회의할 수 있다.
연력 - 음력 달력을 지원하며 기념일을 등록해 놓으면 보여 준다. 스케줄 관리까지는 하지 않는다.
캡처 - 윈도우나 일정 영역을 일시적으로 캡처하여 이미지화한다. 두 화면을 동시에 볼 때 편리하다.
핫키 - 특정 핫키에 커스텀 동작을 정의하고 필요할 때만 선택적으로
사용한다.
추가할 티젯
FolderSize - 지정 디렉토리 이하의 서브디렉토리 각각에 대한
크기 조사. 누가 용량을 많이 먹는지 점검한다.
FindSameFile - 중복 파일 찾기. 이름이나 크기 또는 간단한 지문으로 동일 파일을 찾아내 관리한다.
스톱 와치 - Start, Stop, Lap 등의 기능을 제공하며
전역 핫키를 정의하여 포커스없이도 시간 측정 가능
소스 카운터 - 디렉토리와 대상 확장자를 등록해 두고 총 줄수를 즉시
조사한다. 상세 정보는 별도 창으로 확인
타자 연습 - 심심할 때 키보드로 타자 연습을 수행한다.
각 젯 개선 사항
메모 - 서식 있는 문서를 편집하는 기능 제공. 워드 컨트롤을 도입해야 한다.
이미지 뷰어 - 상단으로 이동시 마우스로 창을 닫을 수 있는 기능
제공. 이전/다음 이미지 이동 기능 제공
SizeMeter - 모니터 해상도를 고려한 실제 길이 표시
음악 재생기 - 이전, 다음
곡에 대해서도 전역 핫키 등록 및 선택 가능. 목록에서 파일 제거 및 삭제
색상표 - 키보드로도 상하좌우 이동 가능하게 할 것
스파이 - 윈도우 계층을 그래픽으로 보여주고 계층간 이동
이미지 슬라이더 - 리스트 박스의 항목을 드래그하여 순서 조정.
전체적인 기능
앱바 형식으로 벽에 도킹시킨다.
각 젯 옵션창 호출 방법이 비직관적이어서 별도의 UI를 만들고 확인, 취소 버튼을 배치한다.
위젯 크기 조정시 굳이 실시간으로 조정하지 말고 음영만 그리는 방법 고려할 것
젯 인터페이스를 표준화하여 커스텀 DLL로 작성 및 기능 확장 가능토록하고
API 공개
아이콘 및 비트맵 버튼 디자인 일괄 정비. 전문 디자이너의 도움이
필요함
팝업창 위쪽의 흰색 띠 제거 방법 연구
1.0 이전에 사이닝 및 보안 문제 해결하고 정식 배포
지금 당장 생각나는 것만 해도 이 정도인데 이 기능을 다 만들고 나면 또 이만큼 할 일이 쌓일 것 같다. 일단 내가 실용적으로 사용하고 있고 몇몇 지인도 사용자가 있어 추가 기능에 대한 요구는 지속적으로 나올 것이다. 디자인이 좀 아마추어적이지만 몇몇 기능은 그래도 꽤나 쓸만한 것 같아 만족스럽다.
강좌를 마치며
이상으로 여기까지 SoEnty 제작 강좌를 종료한다. SoEnty 0.4 버전까지는 혼자 만들다가 일정 양이 되었다 싶어 소스 정리 및 기술 공유 차원에서 0.5 버전을 새로 만들면서 그 제작 절차를 SoEnty01 ~ SoEnty09까지
9개의 프로젝트를 단계별로 작성했다. 최종 SoEnty09가 강좌용 예제의 마지막이며 이 버전이 SoEnty 0.5에
해당한다.
아직도 갈 길은 멀지만 0.5 버전 정도면 그래도 큰 틀은 다 잡았으며
중요한 기술적 토대는 장만했다고 자평한다. 이후에도 개발은 계속 진행할 것이고 틈틈이 위젯과 티젯을
만들겠지만 질적으로 바뀌는 부분은 크게 없을 것이다. 이런 부분에 대해서는 굳이 강좌씩이나 쓸 필요가
없으니 소스만 공개하기로 한다.
이 강좌의 목적은 이런 프로그램을 만드는데 어떤 기술이 사용되며 뭘 더 공부해야 하는지를 공유하기 위해서이다. 문법을 배웠더라도 실제 프로젝트를 해 볼 기회가 없는 새내기 개발자에게 조금이나마 문법을 적용해 보고 실무를
익힐 수 있는 기회가 되기를 바란다. 비록 0.5 버전이
절반 정도이지만 이 정도면 강좌의 목적은 충분히 이룬 것 같다.
SoEnty 프로젝트는 21년
8월 1일 개발을 시작하여 9월 26일까지 근 두 달에 걸쳐 퇴근 후, 주말에 틈틈이 작업하였다. 회사일도 바쁜데 퇴근 후에도 새벽까지
코드를 짜는게 좀 불쌍해 보일 수는 있겠으나 개발자에게 코딩만큼 재미있는 놀이가 없는 것도 사실이다. 시간에
쫒기며 잠을 줄이고 피곤에 쩔어도 내가 만든 기능이 화면에 점점 하나씩 모습을 드러내는 희열이 있다.
개발도 신나는 일이지만 개발한 코드를 강좌로 옮기는 일도 보람찬 일이다. 그러나
강좌는 개발과는 달리 남에게 읽힐 목적으로 쓰는 것이다 보니 신경쓸 것이 많고 원고량이 많다 보니 엄청난 시간과 노력이 소모된다. 이 강좌를 쓰는데 2021년 9월
18일부터 26일까지 9일간의
추석 황금 연휴동안 고향에도 안가고 외출도 하지 않고 방에 틀어박혀 밤낮으로 온전히 다 헌납했다.
직장인이 이 정도 시간을 낼 수 있는 기회는 거의 없으며 솔직히 힘들었다. 그림도
좀 많이 넣고 세부 코드에 대해서도 상세한 설명을 더 달고 싶지만 주어진 시간이 많지 않다 보니 그럴 수가 없었다. 앞으로 이런 기회가 더 오지도 않을 것이고 온다고 해도 다른 할 일도 많아 당분간은 강좌를 업데이트하기 어렵다.
시간 관계상 일단락은 짓지만 이 프로젝트는 계속 진행한다. 개발은
퇴근 후 틈틈이 진행하여 소스는 계속 업데이트할 것이다. 차후 직장을 관두게 되거나 늙었다고 짤리게
된다면 그때는 강좌를 보강할 기회가 있을 것이다. 다음 번 기회가 주어지면 그간의 진행 상황까지 포괄하여
더 꼼꼼하게 원고를 작성하고 싶다. 부디 이 강좌가 프로그래밍에 막 입문한 초보 개발자에게 조금이나마
도움이 되기를 바랄 뿐이다.