'게임 개발/프로그래밍'에 해당되는 글 178건

  1. 2011/12/02 미니덤프만으로는 크래시 원인을 알아내기 어렵습니다.
  2. 2011/10/02 단지 컴파일 속도 향상을 위해서 Pimpl 패턴이나 인터페이스를 사용하진 말 것 (2)
  3. 2011/08/07 리팩토링할 때 주의할 점
  4. 2011/08/01 한/영 전환 감지하기
  5. 2011/08/01 문자열 인코딩 바꾸기
  6. 2011/08/01 디스플레이 장치의 정보를 얻어내기
  7. 2011/07/25 전체 화면일 때에 마우스 커서가 옆 모니터로 나가지 않게 하기
  8. 2011/07/25 timeGetTime의 정밀도를 높이기
  9. 2011/07/21 한/영 입력 모드 알아내기
  10. 2011/07/18 함수의 이름을 얻어내는 매크로
  11. 2011/07/18 디버거에서 배열 값 조사하기
  12. 2011/07/18 지역화 작업용 문자열 처리 함수
  13. 2011/07/18 컴퓨터의 이름을 Windows API로 얻어내기
  14. 2011/07/18 강제로 예외 발생시키기
  15. 2011/07/18 C++에서 정수를 표현할 때 char를 쓰지 말 것
  16. 2011/07/14 함수 호출 대신에 메시지 방식이 필요한 때 (2)
  17. 2011/07/12 디버그 힙 없이 디버깅하기
  18. 2011/07/07 자주 사용하는 netstat 옵션
  19. 2011/07/07 SEH로 처리할 수 없는 예외를 추가로 처리하기
  20. 2011/07/06 C++에서 문자열 내의 특정 문자열을 검색한 후 치환하기
  21. 2011/06/24 호출되는 코드보다 호출하는 코드를 먼저 작성할 것
  22. 2011/06/15 C++ 매크로를 기억해 뒀다가 복구하기
  23. 2011/06/15 IME가 존재하는지 알아내기
  24. 2011/04/01 엑셀 파일 저장 VBA 스크립트
  25. 2011/04/01 엑셀 파일에서 외부 비쥬얼 베이직 스크립트 파일을 실행하기
  26. 2011/04/01 엑셀 파일을 XML로 저장하는 비쥬얼 베이직 스크립트
  27. 2011/03/12 최적화 옵션을 켜고 빌드했을 경우, 디버거의 스택 출력을 믿지 말 것
  28. 2011/02/28 비쥬얼 C++ 2010에서 프로젝트 종속성이 동작하지 않는 문제를 해결하기
  29. 2011/01/25 치명적 오류로 처리하지 않아도 되는 윈속(WinSock) 오류 코드
  30. 2011/01/10 XML 파일을 엑셀(Excel) 2007에서 바로 사용할 수 있게 하기
미니덤프를 이용하면 크래시가 났을 때의 콜 스택, 지역 변수, 그리고 레지스터 등의 정보를 알 수 있습니다. 하지만 이런 정보만으로는 원인을 정확히 알기 어려울 때가 잦습니다.

이럴 때엔 크래시가 자주 발생하는 위치에서 필요한 정보를 지역 변수에 복사하는 방법이 어느 정도 도움이 됩니다. 하지만 좀 더 풍부한 정보를 얻으려면, 힙(heap)의 정보까지 갖고 있는 풀(full) 덤프가 필요합니다. QA 테스트나 사내 테스트처럼 큰 파일도 전송이 가능한 환경에서는 되도록 풀 덤프를 저장하는 게 좋습니다.
2011/12/02 21:39 2011/12/02 21:39
프로그래머 중에 단지 컴파일 속도 향상을 위해서 Pimpl 패턴이나 인터페이스를 사용하는 사람이 많습니다. 하지만 그 방법은 예전엔 좋았을지는 몰라도, 지금은 별로 좋지 않습니다. 단점이 장점보다 더 많기 때문입니다. 그 이유를 나열해 보겠습니다.

첫째, Pimpl 패턴이나 인터페이스를 사용하려면, 레이어 역할을 하는 클래스를 하나 더 만들어야 합니다. 게다가 원래 클래스에서 public이나 protected인 멤버가 변경될 때마다 원래 클래스와 새로 만든 클래스를 모두 바꿔야 합니다. 이렇듯 유지 보수에 추가되는 노력이 꽤 큽니다.

둘째, 빌드할 때 시간을 많이 차지하는 건 컴파일이 아니라 링크입니다. 기능을 충분히 잘게 나눠서 구현하면, 기능 하나를 구현할 때 실제로 고쳐야 하는 소스 파일의 수는 많지 않기 때문입니다. 그 점을 감안하면, 컴파일 속도 향상은 큰 의미가 없습니다. 컴파일 시간은 프리컴파일드 헤더만 잘 활용해도 많이 줄일 수 있습니다. 그리고 인크레디빌드처럼 여러 파일을 분산 컴파일시켜 주는 도구를 활용해도 됩니다. 아니면 컴퓨터를 좋은 것으로 바꾸는 것도 컴파일 속도를 향상시키는 좋은 방법입니다.

셋째, 객체를 스택에 생성할 수 없어서, new와 delete에 들어가는 부하가 생깁니다. 더구나 이 부하는 프로그래머뿐만 아니라 사용자에게도 영향을 줍니다.

Pimpl 패턴이나 인터페이스는 컴파일 속도 향상보다는 구현과 인터페이스를 분리하는 용도로 사용하는 게 낫습니다. 즉 두 개 이상의 구현을 한 개의 인터페이스로 접근할 수 있게 하는 용도인 것입니다.
2011/10/02 12:01 2011/10/02 12:01
리팩토링에서 제일 중요한 것은 기존 코드의 기능을 100% 그대로 유지한 채로 코드만 다듬어야 한다는 것입니다. 즉, 사용자 입장에선 아무런 차이도 느낄 수 없어야 합니다.

자신만의 코드에 욕심이 많은 사람이 종종 저지르는 실수가, 기존 코드를 정리하면서 기능까지 바꿔 버리는 일입니다. 기능이 바뀌어 버리면 기존 테스트 케이스로는 테스트가 불가능하므로, 문제 없이 리팩토링됐는지 쉽게 판단할 수가 없습니다. 또 수정된 기능에 맞춰 연관된 다른 코드도 수정해야 합니다. 그래서 잘못된 리팩토링을 하고 나면, 연관된 코드를 수정하고 숨어 있는 테스트 케이스를 찾으며 버그를 잡느라고 고생하게 됩니다.

잘못된 리팩토링은 차라리 안 하는 게 낫습니다.
2011/08/07 21:50 2011/08/07 21:50
윈도우 메시지 처리 함수에서 다음처럼 처리하면 됩니다.

// 원래는 WM_INPUTLANGCHANGE로 한영 전환을 검출하는 게 맞는데, 일부 컴퓨터에선
// WM_INPUTLANGCHANGE 메시지가 안 와서, IMN_SETCONVERSIONMODE 메시지로 검사해야 합니다.
if (message == WM_INPUTLANGCHANGE || message == WM_IME_NOTIFY && wParam == IMN_SETCONVERSIONMODE)
{
// 한/영 전환 처리
}
2011/08/01 11:16 2011/08/01 11:16
// 인코딩을 직접 바꾸는 것은 어려우므로, UTF-16으로 바꾼 다음에 원하는 인코딩으로 다시 바꾸게 했습니다.
// 참고로, MultiByteToWideChar 함수의 cbMultiByte 인자와 WideCharToMultiByte 함수의 cchWideChar 인자를 -1로 넘겨 주는 게 더
// 편합니다. 하지만 그러면 공문자까지 변환이 되므로, outEncodingText에 공문자가 포함되서 const char*와 호환되지 않는 문제가
// 생깁니다. 그래서 할 수 없이 입력 문자열의 크기도 넘겨 주게 했습니다.
string convert_encoding(UINT in_encoding, UINT out_encoding, const string& in_encoding_text)
{
// 인코딩을 in_encoding에서 UTF-16으로 변환합니다.
int utf16_character_count = MultiByteToWideChar(in_encoding, 0, in_encoding_text.c_str(), in_encoding_text.size(), NULL, 0);
if (utf16_character_count == 0)
return "";
wstring utf16_text(utf16_character_count, L'\0');
MultiByteToWideChar(in_encoding, 0, in_encoding_text.c_str(), in_encoding_text.size(), &utf16_text[0], utf16_character_count);

// 인코딩을 UTF-16에서 out_encoding으로 변환합니다.
int utf8_character_count = WideCharToMultiByte(out_encoding, 0, &utf16_text[0], utf16_text.size(), NULL, 0, NULL, NULL);
if (utf8_character_count == 0)
return "";
string out_encoding_text(utf8_character_count, '\0');
WideCharToMultiByte(out_encoding, 0, &utf16_text[0], utf16_text.size(), &out_encoding_text[0], utf8_character_count, NULL, NULL);

return out_encoding_text;
}

string convert_from_ansi_to_utf8(const string& text)
{
return convert_encoding(CP_ACP, CP_UTF8, text);
}

string convert_from_utf8_to_ansi(const string& text)
{
return convert_encoding(CP_UTF8, CP_ACP, text);
}
2011/08/01 11:13 2011/08/01 11:13
다음처럼 하면 디스플레이 장치의 픽셀당 비트 수, 가로 크기, 세로 크기, 그리고 주파수 등을 얻어낼 수 있습니다.
DEVMODE dev_mode;
dev_mode.dmSize = sizeof dev_mode;
dev_mode.dmDriverExtra = 0;
EnumDisplaySettings(장치 이름, ENUM_CURRENT_SETTINGS, &dev_mode);
2011/08/01 10:53 2011/08/01 10:53
이 방법이 좋은지는 확실하지 않은데, 대체로 잘 동작하는 것 같습니다. 다음 코드를 윈도우 메시지 처리 함수에 추가하면 됩니다.

case WM_ACTIVATEAPP:
case WM_DISPLAYCHANGE:
case WM_MOVE:
case WM_PAINT:
case WM_SIZE:
case WM_WINDOWPOSCHANGED:
RECT clip_rectangle;
GetWindowRect(window_handle, &clip_rectangle);
ClipCursor(&clip_rectangle);
break;
2011/07/25 15:40 2011/07/25 15:40
timeGetTime의 정밀도는 5ms 이상일 수 있습니다. Obtaining and Setting Timer Resolution에 나와 있는 것처럼, 정밀도를 높이려면 다음처럼 timeBeginPeriod 함수를 호출해야 합니다.

// 애플리케이션을 시작할 때 한 번만 설정합니다.
TIMECAPS time_caps;
timeGetDevCaps(&time_caps, sizeof time_caps);
UINT minimum_timer_resolution = time_caps.wPeriodMin;
timeBeginPeriod(minimum_timer_resolution);

// 여기에서 해야 할 일을 합니다.

// 애플리케이션을 종료하기 전에 되돌려야 합니다.
timeEndPeriod(minimum_timer_resolution);
2011/07/25 15:35 2011/07/25 15:35
bool is_native_language_input_mode(HWND window_handle)
{
HIMC ime_context = ImmGetContext(window_handle);
if (ime_context == NULL)
return false;

DWORD conversion;
DWORD sentence;
ImmGetConversionStatus(ime_context, &conversion, &sentence);

ImmReleaseContext(window_handle, ime_context);

return conversion & IME_CMODE_NATIVE;
}
2011/07/21 17:24 2011/07/21 17:24
C++에서 흔히 사용하는 매크로로 __FILE__과 __LINE__이 있는데, 비쥬얼 C++에서는 __FUNCTION__이라는 매크로도 사용할 수 있습니다. 함수의 이름을 표시해야 할 때, 일일이 입력하지 않아도 돼서 유용합니다.
2011/07/18 14:45 2011/07/18 14:45
배열을 watch 창에 추가하면 배열 첫 번째 값만 표시되는데, 다른 부분을 보려면 다음처럼 하면 됩니다.

배열의 보려는 위치, 보려는 요소의 수
예:
array, 1
array + 2, 3

2011/07/18 14:44 2011/07/18 14:44
지역화 작업을 할 때엔 sprintf가 std::ostringstream보다 더 유연해서 낫습니다. 하지만 sprintf는 인자의 순서까지 지정할 수는 없어서, 다국어 지역화 작업에 문제가 생길 수 있습니다.

이럴 때엔 좀 더 유연한 boost::format이 좋습니다. boost::format은 %1%, %2%, ... 이렇게 인자의 순서까지 지정할 수 있어서 어순이 다른 언어에도 적합합니다. 윈도 API인 FormatMessage도 sprintf 대신에 사용할 수 있지만, boost::format이 좀 더 범용적이라 더 좋습니다.
2011/07/18 11:52 2011/07/18 11:52
컴퓨터의 이름을 얻어내는 기능은 디버깅할 때 유용하게 쓰일 때가 있습니다. GetComputerName이라는 API를 사용하면 됩니다.
2011/07/18 11:43 2011/07/18 11:43
강제로 예외를 발생시키는 방법 몇 가지를 적어 봅니다. 상황에 따라 알맞은 방법을 골라서 사용하면 됩니다.

*static_cast<int*>(NULL) = 0;

RaiseException(EXCEPTION_ACCESS_VIOLATION, 0, 0, NULL);

throw "";
2011/07/18 11:36 2011/07/18 11:36
정수를 표현할 때엔 보통 int나 short를 사용하게 되는데, 네트워크 패킷 등에 사용할 때 크기를 줄이려고 char 형을 사용할 때가 있습니다. 그런데 정수로 표현돼야 할 자료를 char 형으로 표현하면, 스트림 관련 함수들이 그 자료를 문자로 인식해서 표현이 제대로 안 되는 문제가 생깁니다. 예를 들면 다음과 같습니다.

char number = 0;
cout << "number is: " << number << endl;

위와 같은 코드에서 number는 실제로 0이라고 출력돼야 하지만 제대로 출력되지 않습니다. number를 공문자 '\0'로 인식해 버리기 때문입니다. 형식을 강제로 지정하는 printf 스타일의 함수를 사용하면 위와 같은 문제를 피할 수는 있지만, 유지보수가 어려워져서 좋지 않습니다.

정수는 되도록 정수형으로 표현하는 게, 문제의 소지를 줄여 줍니다.
2011/07/18 11:29 2011/07/18 11:29
함수 호출 대신에 메시지 방식이 필요한 때는 드문데, 다음 경우엔 유용합니다.

  • 프로세스 간 통신
  • 스레드 간 동기화  (임계 영역 설정을 통한 동기화보다 복잡한 상황이 덜 생깁니다.)
  • undo와 redo의 구현
  • 비동기 처리

그 외의 대부분 상황에선 함수 호출 대신에 메시지 방식을 사용하는 것은 불필요한 복잡함만 가져 옵니다.
2011/07/14 15:30 2011/07/14 15:30
디버거에서 프로그램을 실행시키면 릴리즈 빌드일지라도 디버그 힙(debug heap)을 사용하게 됩니다. 디버그 힙은 메모리를 디버깅하기 쉽게 힙을 특정 값으로 초기화시키는 등의 일을 합니다. 그래서 디버그 힙을 사용하면, 버그가 재현되지 않는 경우가 있습니다. 이럴 때엔 디버그 힙을 사용하지 않으면서 디버깅을 하면 되는데, 간단한 방법은 다음과 같습니다.

디버거에서 Start Debugging 대신에 Start Without Debugging으로 실행시킨 다음에 Attach to Process로 붙입니다. 디버그 힙을 사용할지 여부는 초기 실행 시에 결정되기 때문에 이 방법이 가능합니다.

2011/07/12 18:30 2011/07/12 18:30
netstat -ao

위의 옵션은 도메인 이름을 알고 싶을 때 유용합니다.

netstat -ano

위의 옵션은 IP를 숫자로 정확히 보고 싶을 때 유용합니다.
2011/07/07 10:12 2011/07/07 10:12
Structured Exception Handling(SEH)을 이용하면 대부분의 예외를 처리할 수 있는데, 몇몇 경우는 처리되지 않고 프로그램이 그냥 종료될 때가 있습니다. 다음은 그런 예외를 추가로 잡아내기 위한 코드입니다. 이것 말고도 예외 처리가 더 필요한지는 잘 모르겠습니다.

_set_purecall_handler(handle_pure_virtual_function_call);
_set_abort_behavior(0, _WRITE_ABORT_MSG | _CALL_REPORTFAULT);
signal(SIGABRT, handle_interrupt_signal);
_set_invalid_parameter_handler(handle_invalid_parameter);
2011/07/07 09:49 2011/07/07 09:49
이런 일을 자주 하게 될 때가 많아서 정리해 둡니다. 아래는 a를 b로 바꾸는 예제입니다.

static const string search_string = "a";
for (string::size_type position = 0; (position = a_string.find(search_string, position)) != string::npos; ++position)
    a_string.replace(position, search_string.size(), "b");
2011/07/06 15:26 2011/07/06 15:26
많은 프로그래머들이 호출되는 코드를 호출하는 코드보다 먼저 만드는 경향이 있습니다. 이렇게 작성된 코드는 실제로 사용할 때의 상황이 고려되지 않아서, 사용하기 불편하며 유지 보수하기에도 좋지 않습니다.

예를 들어, 자료 몇 개의 평균을 구해서 출력하는 프로그램을 짠다고 생각해 보겠습니다.

호출되는 코드를 먼저 만들면 다음처럼 진행됩니다. 평균을 구하는 함수 작성, 출력하는 함수 작성, 두 함수를 포함하는 클래스 작성, 그 클래스를 사용하는 함수 작성. 이런 경우 평균을 구하는 함수를 만들 때엔 int 형을 받아서 처리하는 걸 만들었는데, 실제로 사용하려고 보니 float 형만 넘기게 돼서 float로 바꾸게 될 수 있습니다. 이 방식에서는 이렇게 다음 단계로 가다가 다시 처음으로 돌아가서 수정해야 하는 일이 자주 생깁니다.

반면에 호출하는 코드를 먼저 만들면 다음처럼 진행됩니다. 평균 출력 클래스를 사용하는 함수 작성, 두 함수를 포함하는 클래스 작성, 평균을 구하는 함수 작성, 출력하는 함수 작성. 이렇게 만들면 각 기능은 정말 필요한 일만 하게 되므로, 불필요한 군더더기가 없을 뿐만 아니라 다시 처음으로 돌아가서 고쳐야 하는 일이 줄어듭니다.

일을 할 때엔 순서도 중요합니다. 어떤 순서로 일하면 좋을지 계속 생각해 봐야 합니다.
2011/06/24 01:04 2011/06/24 01:04
매크로 충돌 문제 때문에 매크로를 기억해 뒀다가 복구해야 하는 때가 가끔 있습니다. 그럴 때엔 아래처럼 하면 됩니다.

#pragma push_macro("some_macro")

...

#pragma pop_macro("some_macro")
2011/06/15 18:14 2011/06/15 18:14
아래처럼 하면 됩니다. 참고로, ImmIsIME를 이용해서 IME가 존재하는지 판단하는 방법은 잘 동작하지 않습니다. 예외적인 경우가 많기 때문입니다.

HKL input_locale_identifier = GetKeyboardLayout(0);
WORD language_identifier = reinterpret_cast<int>(input_locale_identifier) & 0xffff;

switch (PRIMARYLANGID(language_identifier))
{
case LANG_CHINESE:
case LANG_JAPANESE:
case LANG_KOREAN:
    // IME 존재
}
2011/06/15 18:10 2011/06/15 18:10
ActiveWorkbook.SaveAs Filename:=ActiveWorkbook.Path & "\" & ActiveWorkbook.Name, FileFormat:=xlOpenXMLWorkbookMacroEnabled
2011/04/01 11:21 2011/04/01 11:21
여러 엑셀 파일에서  같은 비쥬얼 베이직 스크립트 코드를 쓰는 경우, 각 엑셀 파일마다 똑같은 스크립트 코드를 넣어 놓으면 관리하기 불편합니다. 이걸 해결하려면 공통 스크립트 코드를 .bas 파일로 분리하고, 그걸 엑셀에서 부르게 하면 됩니다. 대략 다음처럼 하면 되는 것 같습니다.
Sub DoFunction()
    ActiveWorkbook.VBProject.VBComponents.Import ActiveWorkbook.Path & "\example.bas"
    Application.Run ActiveWorkbook.Name & "!Module1.Function"
    ActiveWorkbook.VBProject.VBComponents.Remove ActiveWorkbook.VBProject.VBComponents("Module1")
End Sub
참고로, 맨 밑의 VBComponents.Remove를 호출하는 이유는 계속 import를 하게 되면 Module이 계속 늘어나기 때문입니다.

위의 코드를 실행하려면 엑셀 옵션도 수정해 둬야 합니다. 'Excel 옵션 -> 보안 센터 -> 보안 센터 설정 -> 매크로 설정 -> 모든 매크로 포함, VBA 프로젝트 개체 모델에 안전하게 액세스할 수 있음'을 켜 두면 됩니다.

참고:
2011/04/01 11:20 2011/04/01 11:20
엑셀 파일을 일반적인 XML 파일 형태로 저장하는 게 쉽지 않아서, 방법을 조사하다가 다음과 같은 스크립트를 작성하게 됐습니다. 편집은 엑셀로 하고 데이터 교환은 XML로 하고 싶을 때 유용할 듯합니다.

참고로, ADODB를 사용한 이유는 UTF-8 인코딩을 위해서입니다.
Sub SaveAsXMLAndXLSM()
    Dim extension As String
    Dim fileNameExcludingExtension As String
    Dim XMLFileName As String
    Dim adoStream As Object
    Dim rowIndex As Long
    Dim columnIndex As Integer
    Dim cellValue As String
    Const adSaveCreateOverWrite = 2

    extension = ".xlsm"
    
    fileNameExcludingExtension = Left(ActiveWorkbook.Name, Len(ActiveWorkbook.Name) - Len(extension))
    
    Set adoStream = CreateObject("ADODB.Stream")
    adoStream.Open
    adoStream.position = 0
    adoStream.Charset = "UTF-8"
    
    adoStream.WriteText "<?xml version=""1.0"" encoding=""utf-8""?>" & vbCrLf
    adoStream.WriteText "<root>" & vbCrLf
    
    For rowIndex = 2 To ActiveSheet.UsedRange.Rows.Count
        adoStream.WriteText Chr(9) & "<row>" & vbCrLf
        For columnIndex = 1 To ActiveSheet.UsedRange.Columns.Count
            columnName = ActiveSheet.Cells(1, columnIndex).Text
            cellValue = ActiveSheet.Cells(rowIndex, columnIndex).Text
            If (IsNull(cellValue)) Then cellValue = ""
            adoStream.WriteText Chr(9) & Chr(9) & "<" & columnName & ">" & ReplaceReservedSymbol(cellValue) & "</" & columnName & ">" & vbCrLf
        Next columnIndex
        adoStream.WriteText Chr(9) & "</row>" & vbCrLf
    Next rowIndex
    
    adoStream.WriteText "</root>" & vbCrLf
    
    XMLFileName = ActiveWorkbook.Path & "\" & fileNameExcludingExtension & ".xml"
    adoStream.SaveToFile XMLFileName, adSaveCreateOverWrite
    adoStream.Close
    Set adoStream = Nothing
End Sub

Function ReplaceReservedSymbol(aString As String) As String
    ReplaceReservedSymbol = aString
    ReplaceReservedSymbol = Replace(ReplaceReservedSymbol, "&", "&amp;")
    ReplaceReservedSymbol = Replace(ReplaceReservedSymbol, "<", "&lt;")
    ReplaceReservedSymbol = Replace(ReplaceReservedSymbol, ">", "&gt;")
    ReplaceReservedSymbol = Replace(ReplaceReservedSymbol, """", "&quot;")
    ReplaceReservedSymbol = Replace(ReplaceReservedSymbol, "'", "&apos;")
End Function
참고:
2011/04/01 01:02 2011/04/01 01:02
비쥬얼 C++에서만 해당되는 내용이지만, 최적화 옵션을 켜고 빌드하면 스택에 있는 지역 변수의 내용이 디버거에서 제대로 표시되지 않습니다. 이것은 프레임 포인터 생략을 옵션에서 설정하지 않아도 마찬가지입니다. 따라서, 최적화 옵션을 켠 상태에서 디버깅할 때엔 주의해야 합니다. 왜냐하면 엉뚱한 정보를 통해서 오판할 수 있기 때문입니다.
2011/03/12 16:47 2011/03/12 16:47
비쥬얼 C++ 2010에서 프로젝트를 빌드해 보니, 솔루션 내의 다른 라이브러리가 링크되지 않는 문제가 생겼습니다. 링커의 추가 종속성에 라이브러리 경로를 넣으면 링크가 되긴 했지만, 이렇게 하면 프로젝트 관리가 번거로워지므로 원래 방법과 비슷한 다른 방법을 찾아야 했습니다.

구글에서 검색해 보니, Static Library Dependencies in Visual Studio 2010라는 글이 있었고, 그 글을 읽고 다음처럼 프로젝트 종속성을 설정하면 된다는 것을 알았습니다.

프로젝트 속성 -> 공용 속성 -> 프레임워크 및 참조 -> 새 참조 추가
2011/02/28 18:37 2011/02/28 18:37
윈속 네트워크 프로그래밍을 하다 보면, 다양한 오류 코드를 만나게 됩니다. 그런데 어떤 오류 코드는 무시해도 되고, 어떤 오류 코드는 소켓을 닫아야 할 정도로 치명적입니다. 정해진 기준은 없지만, 대략 다음 오류 코드는 치명적 오류로 처리하지 않아도 될 것 같습니다. 어떤 오류를 무시해도 되는지 알 수 없을 때엔 일단 치명적 오류로 처리하고, 지나치게 자주 발생하고 복구 가능하다면 그때 무시하게 바꿔도 됩니다.
WSAECONNRESET: UDP 소켓일 때만 무시해도 됩니다.
WSAEINPROGRESS: 무시해도 되는지 명확하지 않은데, 좀 더 확인이 필요합니다.
WSAEINTR: 무시해도 되는지 명확하지 않은데, 좀 더 확인이 필요합니다.
WSAEWOULDBLOCK: 나중에 재시도 처리하면 됩니다.
참고: Appendix C: Error Reference
2011/01/25 18:12 2011/01/25 18:12
엑셀 2007에서 XML 파일을 가져오거나 내보낼 수 있는 기능을 제공하는데, 이게 생각처럼 잘 안 됩니다. 그래서 간단히 정리해 둡니다. 아래에서 설명한 방법 말고, 다른 방법도 있을 것입니다.

다음 예제의 XML 파일 구조를 메모장에서 입력하고 .xml 파일로 저장합니다. 그리고 엑셀에서 불러 옵니다.

<root>
<row>
<column1>row1_column1</column1>
<column2>row1_column2</column2>
</row>
<row>
<column1>row2_column1</column1>
<column2>row2_column2</column2>
</row>
</root>

중요한 것은 자료가 최소 2행 이상 있어야 엑셀에서 XML 파일로 인식된다는 것입니다. 즉, 위 예제에선 row 노드가 2개 이상 있어야 합니다. 이건 아마도 엑셀의 버그인 것 같습니다.

위의 형식대로 파일을 만들어서 엑셀에서 정상적으로 읽으면, 각 열 맨 위에 태그 이름과 드롭다운 화살표가 표시될 것입니다. 이후부터는 해당 XML 파일을 엑셀에서 바로 편집하고 저장할 수 있게 됩니다.

이 방법의 큰 단점은 엑셀에서 행이나 열을 추가해서 XML로 저장하면 변경된 구조가 제대로 저장이 안 된다는 것입니다. 대안으로는 엑셀 파일에 XML 파일로 저장하는 VBA 코드를 넣는 방법이 있습니다.
2011/01/10 18:21 2011/01/10 18:21