JHB의 삽질 이야기

사용할 프로그램은 멀티 바이트로 작성하였고, DLL은 유니코드로 작성 하였는데, 프로그램에서 DLL을 불러서 사용하려고 하니 에러가 났다. 에러 내용은 다음과 같았다. error LNK2001: unresolved external symbol "__declspec(dllimport) public: int __thiscall StartCapture(class ATL::CStringT)" (__imp_?StartCapture@@QAEHV?$CStringT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@@Z) 2>D:\실행파일.exe : fatal error LNK1120: 1 unresolved externals CString이 유니코드와 멀티바이트 일때 각각 다..

이번에 프로그램 UI를 일본어로 바꿈에 있어서 상당한 난항에 처한적이 많다. 이것 저것 다 제쳐놓고, 우선 폰트 관련된 이슈만 보더라도 그렇다. 분명히 폰트 바꿔주었는데 출력이 안되는 경우이다. 우선 MS UI Gothic이라는 폰트를 사용했었는데 안나오길래 도대체 이건 무슨 신의 장난인가.. 싶었는데 LoadString 이후에 font를 SetFont 해주는 것과 SetFont 이후 LoadString 해주는 것에 차이가 있었다.. 즉 LoadString으로 멀티바이트에서 SHIFT_JIS로 인코딩된 일본어를 읽어온 후 일치하는 폰트가 없으면 MFC Control에 값이 이상하게 들어가나보다. 지원되지 않는 폰트 일 경우 아예 스트림이 다르게 들어가 버리나...? 하여튼 이번 프로젝트 하면서 느낀건데 ..

아래 내용이 일부 틀려서 정정합니다. 20110719. 아래 처럼 할 경우 폰트가 변경 되는 것이 맞긴 한데, '일본어'등의 특수 문자들을 불러서 Insert하는 경우에 문제가 생긴다. 일본어를 지원하지 않는 폰트가 set돼있는 트리컨트롤에 일본어 String을 insert하려하면 항목이 깨져버린다. 그 이후에 font를 바꿔봤자 이미 삽입된 항목은 깨진 뒤다. 아래서 적은 NMCustomDraw는 삽입 된 뒤에 그려지는 듯 하다. 따라서 font를 적용시킬려면 그냥 CTreeCtrl로 객체를 생성하자마자 SetFont로 폰트를 지정하면 되는 듯 하다. 만약 CTreeCtrl을 상속받은 CustomTreeControl이라면 PreSubclassWindow 메소드에서 SetFont해주도록 하자. -----..

프로그램의 솔루션 디렉토리를 선택 하면 해당 프로그램에 들어간 소스의 라인 수를 계산하여 출력해 주는 프로그램. 현재 c, cpp, h, java, cs, py 확장자만 지원한다. 소스는 너무 간단해서.. 걍 대충 주석써서 올리겠음. void CCodeLineSearcherDlg::FindLine( int &nTotalLine, CString strPath ) { CFileFind finder; finder.FindFile( strPath ); int res = 1; while( res ) { res = finder.FindNextFile(); if( ( m_bC && finder.GetFileName().Right(2) == _T(".c") ) || ( m_bCPP && finder.GetFileNam..

C, C++ 에서는 프로그램 실행시 명령 인자를 받을 때 argv를 통해서 쉽게 받아 올 수 있다. MFC에서는 어떻게 얻어올까? GetCommandLine(); 을 쓰면 얻어 올 수 있다. 백문이 불여일견. 한번 테스트 직접 해보시길. 그리고 아래는 인자를 쫙 얻어오는 예제 소스. 띄어쓰기(공백)이 제대로 분리 됐는지 확인 하기 위해 출력 시에 @를 시작과 끝에 붙여서 출력 시켰다. 파싱은 알아서 하면 됨. LPSTR pszArgv = GetCommandLine(); CString strArgv = pszArgv; int nFirstSpace = strArgv.Find( _T(" ") ); CString strFirstArgv = strArgv.Mid( nFirstSpace + 2 ); AfxMessa..

Registry read, write. 레지스트리를 입력하거나 읽을려면 RegSetValueEX, RegQueryValueEx등을 써야하는데 들어가는 인자 셋팅하는게 귀찮다. 따라서 다음과 같이 쉽게 쓰도록 만들어주면 좋다. 우선 쓰기. //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// /// Registry에서 string value 쓰는 함수. /// ///@param[in]hKey쓸 값이 존재하는 키, { HKEY_LOCAL_MACHINE, HKEY_CLASSES_ROOT, ...} 등의 값 사용. ///@param[in..

멀티바이트와 유니코드간의 교환! 문제 : LoadString이 이상한 문자를 읽어와요 rc의 StringTable에 있는 스트링을 읽어 오려면 기본적으로 LoadString을 사용 한다. 이 LoadString은, rc파일의 인코딩이 한글(euc-kr, cp949)일 경우, 한글 윈도우에서 한글을 읽어 오는 것은 문제가 되지 않는다. 마찬가지로 인코딩이 일본어(shift_jis, cp932)일 경우, 일본 윈도우에서 일본어를 읽어 오는 것은 문제가 되지 않는다. 하지만 나는 매우 특별한 상황에 쳐하였으니 -.-;; cp949로 인코딩 된 일본어(Japanese)를 일본OS에서 불러와야 하는 상황이 발생 하였다. 현재 사용하는 프로그램이 멀티바이트로 작성 돼 있다는 점을 명심하고, 우선 StringTabl..

현재 다루고 있는 프로그램은 캐릭터 표현에 있어서 멀티 바이트를 사용한다. 따라서 OS에 따라서 언어 인코딩 방식이 달라진다... 영어만 생각한다면 큰 문제가 없을텐데 일본어 버전 OS에서는 큰 문제가 발생 하더라. 특히 LoadString 매크로 함수에서 가장 큰 문제가 발생 한다. euc_kr로 인코딩 돼있는 리소스(.rc) 파일을 한글 윈도우에서 컴파일 하여 일본 os에서 실행 하는 경우 일본어가 들어있을 때, LoadString이 일본어를 읽어오질 못한다. 곰곰히 생각해보니 일본어 윈도우에서는 LoadString 함수가 shift_jis (cp932) 로 읽어와서 컨버팅 하는 것 같다. 현재 이런 저런 시도를 일주일 째 하고 있지만 차도가 보이질 않는다.. 유니코드와 멀티바이트: http://jh..