이 기술 노트는 주로 MFC 2.0 도구를 MFC 1.0 응용 프로그램 마이그레이션에 대 한 지침을 제공합니다. 아래의 첫 번째 섹션에서 제시 하는 MFC 2.0, 2.5, 및 3.0 추가 차이점。
MFC 4.0/3.0 API 변경
변경 해야 하는 기존 코드를 발생할 것 이라고 하는 문서화 된 MFC Api로 알려진 변경이 없습니다. 저기, 물론, 많은 추가 기능을 활용 하는 것이 좋습니다. 이러한 기능에 자세한 내용은 다음 웹 사이트를 참조 하십시오. Visual c + + 프로그래머 가이드。
MFC 2.5 API 변경
클래스 라이브러리에 두 가지 주요 기능을 추가 하는 MFC 2.5: OLE 1.0 지원 및 데이터베이스 액세스를 제공 하는 ODBC 지원 대체 OLE 2.0 지원 합니다. 그것은 기존 코드에 영향을 미칠 수 있습니다 API 변경 커버이 technote 의도입니다. 이 technote에서 다루지 않는 이러한 새로운 기능에 대 한 내용은 다음 웹 사이트를 참조 하십시오. Visual c + + 프로그래머 가이드。
CFrameWnd::RecalcLayout 에 추가 매개 변수, BOOL bNotify. 이 OLE 서버에 알림 여부를 지정 합니다 그들은 레이아웃 변경 되었습니다. 일반적으로 사실이 하 고 따라서 기본값입니다. 이 함수는 프로그램에서는이 함수를 재정의 하는 경우에 귀하의 함수를 추가 매개 변수를 추가 해야 하므로 가상,。
ODBC와 OLE 2.0을 지원 하기 위해 MFC 2.5 라이브러리에 문서화 되지 않은 기능을 변경 했다. 여전히 유효한 있는지 확인 등 모든 사용을 검토 해야 프로그램 문서화 MFC Api를 사용 하는 경우。
마이그레이션 MFC 1.0 mfc 2.0 응용 프로그램
중요: 이해 하 고 평가 하는 아래에 제시 하는 두 가지 방법, 해야 문서 뷰 아키텍처 및 도구와 같은 MFC 2.0 개념을 잘 알고 있습니다. 적어도 MFC 자습서 샘플을 통해 작동 하는 것이 좋습니다 기존 코드의 모든 마이그레이션을 시작 하기 전에 자습서 낙서。
거기에 두 가지 기본 접근 마이그레이션할 기존 응용 프로그램을 MFC 버전 1에서에서 Microsoft C7 mfc 버전 2와 함께 출시。
최소한의 마이그레이션
필요한 최소 사항만 변경 "최소" 마이그레이션 방법을 사용 하는:
이것은 가장 쉬운 접근 하지만 그것 MFC 2.0 라이브러리에 풍부한 기능 활용 받지 않습니다. 이해 하 고 최소한의 마이그레이션에 대 한 기술을 연습 해야 "" 전체 마이그레이션 방법을 선택 하는 경우에。
전체 마이그레이션
"전체 마이그레이션"을 수행 하는 경우 MFC 2.0 라이브러리의 활용을 걸릴 수 있습니다. 최소 마이그레이션 방법을 사용 하 여, 당신은 Visual c + + 클래스 마법사를 사용 하 여 응용 프로그램을 편집할 수 있게 됩니다. 전체 마이그레이션 방법을 사용 하 여 당신이 얻을 다음 MFC 2.0 지원:
전반적인 전체 마이그레이션 방법은 기본적으로 에뮬레이션 AppWizard 시작부터 MFC 2.0 응용 프로그램을 개발입니다. 처음부터 MFC 2.0 응용 프로그램 개발에서 코스의 차이가 많은 일리가 쓴 MFC 1.0 코드를 빌려 것입니다.
최소한의 마이그레이션
다음 하위 섹션 최소한의 마이그레이션 수행에 대 한 자세한 지침을 제시。
Windows 3.1 엄격한 typedef에 부합
기본 라이브러리 Windows 3.1 SDK에서 설명 하는 Windows 3.1 STRICT typedef를 준수 하는 MFC 2.0의 빌드합니다. MFC 1.0 STRICT 해제 했지만 지금은 MFC 2.0 STRICT 기본적으로 켜져 있다. 이 MFC의 헌신을 업계 표준 Windows API 추적 하 고 육성하는 강력한 응용 프로그램을 쉽게 개발 개발 사례를 다음과 같습니다. 마찬가지로 STRICT typedef 강력한 소프트웨어를 생산 하는 MFC 2.0 클래스의 개발자에 게 도움이 되었다, 그래서 그 것 개발 하는 응용 프로그램 코드에 대 한 사실。
STRICT 형식 검사를 처음으로 사용할 때 많은 컴파일 오류가 일반적으로 발생 합니다. 아주 잘 최소한 마이그레이션 작업의 대부분을 나타낼 수 있습니다 MFC 1.0 응용 프로그램 Windows 3.1 STRICT typedef에 맞게 수정。
응용 프로그램 STRICT를 준수, 일단 추가 변경 없이 실행 파일을 컴파일할 수 있습니다. 예를 들어, ABOUT2 및 FILEVIEW MFC 1.0 샘플 추가 변경 없이 컴파일합니다. 그들은 이미 STRICT 규격 및 않았다 사용 하지 변경 MFC Api。
MFC 2.0 API 변경
STRICT를 준수를 넘어 최소한 마이그레이션 하 고 노력 중 대부분은 식별 하 고 상대적으로 적은 MFC 2.0 API 변화에 부합 하는 응용 프로그램 코드를 변경。
1800 MFC 1.0 Api의만 20 했다 Api의 컴파일 타임 오류에서 결과 변경. 이러한 변경 내용은 사소한 수정만 기존 MFC 1.0 응용 프로그램에 필요합니다. 가장 광범위 한 변경이 OLE 클래스의 건축 구조 조정입니다. 이러한 변경 내용은 기술 노트 18 에 덮여 있다。
변경 하면 예상 해야 확인이 technote 끝 "알파벳 API 변경" 섹션을 참조 하십시오. MFC 2.0에서 수정 된 MFC 1.0 Api는 유용 하 고 간단한 요약 제공。
당신이 하지 않는 경우 모든 변경 내용은 MFC 2.0 코드를 처리 하는 데 필요한, 다양 한 컴파일 및 연결 오류를 얻을 것 이다. 이러한 오류는 거의 항상 쉽게 진단할 수 있습니다. 우리 섹션 "컴파일러 오류"이이 technote 끝에 몇 가지 지침을 제공 하는 귀하의 진단 지원,。
다음 MFC Api MFC 2.0에서 제거 되었습니다. 적절 한 Api를 대체 하는 것이 좋습니다. 이 목록에는 문서화 되지 않은 Api 구현 하는 변경。
CDC::GetDCOrg
GetDCOrg 는 win32에서 사용할 수 있습니다. Windows 3.x 응용 프로그램만, Windows API를 호출 그냥 :: GetDCOrg 직접。
CRuntimeClass::m_pszClassName
이 멤버 변수 메모리 모델 종속 (char *) 보다는 오히려 LPSTR 되었습니다. MFC 2.0에서 m_lpszClassName 라는。
CMDIChildWnd::m_pMDIFrameWnd
이 멤버 변수 클래스의 MDIFrame 부모를 지적 하는 MFC 1.0. 이 멤버 변수 멤버 함수 CMDIChildWnd::GetMDIFrame로 대체 되었습니다. MFC 2.0에서 다중 문서 인터페이스 (MDI) 사용 하는 경우 대부분의 사용 CMDIChildWnd::m_pMDIFrameWnd (또는 GetMDIFrame)는 더 이상 필요한 기본 MDI 지원을 모든 표준 MDI 창 메뉴 명령 처리 이후。
CFrameWnd::GetChildFrame
MDI 프레임 대신 CMDIFrameWnd::MDIGetActive 사용。
다음 API 1 호환성을 지원 하기 위해 MFC 2.0에서 왼쪽 하지만 무용지물이 다. MFC의 이후 버전에서 제거 될 것입니다.
CMDIFrameWnd::CreateClient
이 기능은 뷰 생성 및 MFC 2.0 MDI 지원 향상된을 지 원하는 보다 일반적인 OnCreateClient 메커니즘에 의해 변경 되었습니다. 원래 CreateClient 는 ( CMDIFrame::MDISetMenu사용) 하 여 자신의 MDI 프레임 창의 메뉴 모음을 관리 하는 MDI 응용 프로그램에 계속 사용할 수 있습니다. MFC 2.0 MDI 지원을 자동으로 현재 활성 상태인 MDI 자식 창에 대 한 메뉴 MDI 프레임 창의 메뉴 표시줄 전환 됩니다.
다른 API 관련 변경 사항
두 MFC 클래스 afxext.h 헤더 파일에서 afxwin.h에서 옮겼습니다.:
이러한 클래스를 참조 하는.cpp 파일에 추가 합니다.:
# include lt;afxext.h>
'Const' 한정자를 사용 하는 방법에 대 한 엄격한 수 있도록 많은 Api 변경 되었습니다. 이러한 변경 내용은 LPCSTR 형식 이름 및 새 LPCRECT 유형 이름을 보다 일관성 있게 사용 결과. Note, 거기에 없습니다 컴파일 시간 문제가 이러한 변경 때문에 모든 종류를 인수로 사용 하는 경우 해당 형식의 const 버전으로 승격 될 수 있습니다. STRICT 변화 처럼이 리드 더 강력한 코드를 귀하의 코드는 const 데이터 포인터를 사용 하는 경우。
이제 아래에 나열 된 창 만들기 기능 추가 매개 변수 하지만 마지막 매개 변수 기본값 NULL 이후 기존 코드가 수정 없이 작동 합니다. 이러한 함수는
다음 함수 MFC 1.0에서 가상 있었지만 이제 MFC 2.0에서 파생할:
MFC 1.0 응용 프로그램의 파생된 클래스에서 이러한 함수 중 하나를 재정의 하는 경우 MFC 2.0에서 파생 된 클래스에서 함수를 호출할 것입니다 가능성이 크다. 또한, GetParentFrame 는 이동 CFrameWnd 에서 CWnd 더 일반적으로 유용한 API 수。
전역 연산자/친구 기능 뿐 아니라 클래스의 모든 정적 멤버는 이제 파스칼 호출 규칙을 준수 합니다. 모든 전역 함수는 AFXAPI (파스칼). 다시 말하지만,이 컴파일 타임 문제가 되지 않습니다 하지만 빠르고 작은 생성 된 코드를 리드。
많은 구현 전용 클래스와 구조체의 'C' 접두사를 사용 하지 않도록 변경 되었습니다. 예를 들어, CExceptionContext AFX_EXCEPTION_CONTEXT이름이 되었습니다. 이러한 클래스 문서화 되어 있지 않습니다 및 클래스 라이브러리의 구현 세부 사항을 유지 합니다. 이에 의존 하 고 일반적으로 좋습니다는 당신이에 의존 하지 않는 문서화 되지 않은 Api 클래스 라이브러리의 향후 버전에서 변경 될 수 때문에 가능성이 아니다.
MFC 2.0 기본 동작 변경
MFC API 변화를 다루는 컴파일러와 링커 오류가의 원조와 함께 쉽습니다. 하지만 모든 라이브러리 변경 라이브러리 헤더 파일에 공개 됩니다. 일부 변경 내용이 응용 프로그램의 런타임 동작에 공개 됩니다. 이러한 변화는 일반적으로 하지, 처리 하기 어려운 만큼 당신이 그들을 예상. 이러한 행동 변화를 예측 하는 데는 다음과 같은 정보가 제공 됩니다.
CDialog 및 CModalDialog 단일 클래스로 병합 되었습니다. CModalDialog 이제 오래 된 클래스로 간주 됩니다. 그러나 MFC 1.0 호환성에 대 한 CModalDialog 에 대 한 모든 참조는 여전히 유효 afxwin.h에 마이그레이션 매크로 통해:
# define CModalDialog CDialog
대부분의 MFC 1.0 응용 프로그램에 대 한이 간단한 # define 충분 합니다. 그러나, 거기에 경우가이 # define 충분 하지 않습니다.
모덜리스 대화 상자 구현 OnOK 및 OnCancel기본 "" 아무것도 하지 않고 동작에 의존 하는 경우 다음 재정의 해야 합니다 이러한 및 기본 동작 때문에 그들은 지금 전화 EndDialog (모달 대화 처리)。
CDialog::CreateIndirect 는 아직도 모덜리스 대화 상자를 만듭니다. 만들려면 모달 대화 상자 제거 CModalDialog::CreateIndirect API 대신 CDialog::InitModalIndirect 를 사용합니다。
대화 상자와 메시지 상자 배경 색상 지금 세계적으로 설정할 수 CWinApp::SetDialogBkColor API를 사용 하 여. 연한 회색 (하지 COLOR_BTNFACE) 생산 회색 배경 색을 설정 하는 기본 매개 변수. 다른 색상을 지정할 수 있습니다.
SetDialogBkColor 경우 CWinApp에서 호출 되지 않습니다-파생 InitInstance 함수, 기본 창 배경 색 (컨트롤 패널 컬러 애플릿 설정) 사용。
MFC 1.0에서 DLL CWinApp 개체를 포함 하는 경우 그것은 AfxWinTerm에 대 한 호출을 포함 하는 DllMain 을 제공 하는 데 필요한 했다. MFC 2.0 제공이 DllMain, 그래서 어떤 추가 코드에 포함 된 DLL의 CWinApp::ExitInstance 멤버 함수를 DllMain 을 마이그레이션해야。
CMDIChildWnd::Create 이제 올바르게 dwStyle 매개 변수를 사용 합니다. 이제 MDI 자식 창에 대 한 완전 한 창 스타일을 지정 해야 합니다. DwStyle 를 지정 하는 경우 = 0, 이제 CMDIChildWnd::PreCreateWindow에서 ASSERT 오류를 얻을 것 이다. 이 문제를 방지 하려면 WS_CHILD 스타일이 지정 해야 (ko) | WS_VISIBLE (KO) | MFC 1.0과 호환 되도록 WS_OVERLAPPEDWINDOW。
원하는 프레임 창 컨트롤 중 일부를 제거할 수 있도록 MDI 자식 창에 대 한 다른 스타일 설정은 MFC 2.0 지원。
클래스 CFrameWnd 새 데이터 멤버, BOOL CFrameWnd::m_bAutoMenuEnable있다. 설정은 기본적으로 TRUE로. 이 메뉴 항목을 자동으로 비활성화 됩니다 ON_UPDATE_COMMAND_UI 또는 ON_COMMAND 처리기 없어 발생 합니다. ON_COMMAND 처리기, 하지만 아무 ON_UPDATE_COMMAND_UI 처리기는 메뉴 항목을 자동으로 활성화 됩니다.
이것은 현재 선택 영역에 따라 선택적 명령을 구현 하기 쉬운. 또한,이 메뉴 항목의 활성화/비활성화에 대 한 ON_UPDATE_COMMAND_UI 처리기를 작성 하는 응용 프로그램에 대 한 필요성을 크게 줄어듭니다. 예를 들어, 마법사 생성 응용 프로그램 편집 잘라내기/복사/붙여넣기 그들에 대 한 처리기를 구현 하는 프로그래머까지 해제 해야한다。
그러나 MFC 1.0 응용 프로그램 ON_COMMAND 및 ON_UPDATE_COMMAND_UI 처리기를 사용 하 여 업데이트 되지 않은 경우 다음 그것은 지워야 m_bAutoMenuEnable 명시적으로 합니다. 메뉴 비활성화 하면 자동으로 다시 그렇지 않으면。
프로젝트 (빌드) 변경
표준 makefile을 사용 하 여 MFC 1.0 응용 프로그램 구축을 계속할 수 있습니다. 지금까지 프로젝트를 마이그레이션하는 가장 쉬운 방법은 Visual c + + 프로젝트 시설을 사용 하 여 귀하의 depedencies 및 Visual c + + 환경 내에서 다른 프로젝트 옵션을 유지 하는。
일반적인 링크 오류 COMDLG32 해결 되지 않은 외관입니다.DLL 및 shell32입니다.DLL Api입니다. COMDLG32 함께 연결 해야 합니다.LIB 및 shell32입니다.LIB。
빌드를 향상 시킬 수 있습니다 #를 배치 하 여 시간 포함 lt;afxwin.h > 미리 컴파일된 헤더에 있습니다. 규칙에 따라 MFC 2.0 응용 프로그램 미리 컴파일된 헤더 "stdafx.h"를 지정합니다. 다음 모듈 stdafx.cpp stdafx.h를 포함합니다. 이 기술은 AppWizard, 그리고 많은 MFC 2.0 샘플을 만든 코드에 의해 일러스트。
메모nbsp;??정의 stdafx.h에서는 _AFX_NO_XXX 매크로 중 하나를 모두 중요 하다. 기술 자료 문서 "PRB: _AFX_NO_XXX 정의할 때 문제가 발생 합니다." MSDN 라이브러리 CD 또는 http://www.microsoft.com/kb/에서 기술 자료 문서를 찾을 수 있습니다(&N).
Visual c + + 및 ClassWizard 호환성
도 최소한의 마이그레이션에 대 한 아래의 단계를 수행 하는 것이 좋습니다 Visual c + +와 Classwizard를 사용 하 여 응용 프로그램 리소스 및 코드를 편집할 수 있도록。
//{{AFX_MSG_MAP (lt; 클래스 이름 >)
//}}AFX_MSG_MAP
lt; 클래스 이름 > 메시지 맵에 포함 된 클래스의 이름입니다。
마찬가지로, 귀하의.h 파일에 해당 클래스 선언 내부에 다음과 같은 두 개의 주석 줄을 추가:
//{{AFX_MSG (lt; 클래스 이름 >)
//}}AFX_MSG
이러한 선언 등 Appwizard에서 만든 모든 응용 프로그램에서 동일한 주석 줄 봐. 에 대 한 설명은 설명 줄이 의미를 참조 하십시오 MFC: MFC 소스 파일을 사용 하 여 Visual c + + 프로그래머 가이드。
//{{AFX_VIRTUAL (lt; 클래스 이름 >)
//}}AFX_VIRTUAL
전체 마이그레이션
MFC 2.0 기존 C 또는 MFC 1.0 응용 프로그램의 전체 마이그레이션 MFC 2.0의 모든 장점을 제공할 것입니다. 대부분의 응용 프로그램에 대 한 전체 마이그레이션 어렵지 않다 하 고 잘 노력이 가치가 있다。
MFC 2.0 응용 프로그램의 성공적인 전체 마이그레이션 처음부터 새로운 응용 프로그램 개발로 MFC 2.0의 본질적으로 같은 이해를 필요 합니다. 전체 마이그레이션을 시작 하기 전에 MFC 2.0 클래스 라이브러리, Visual c + +, AppWizard 및 Classwizard에 잘 알아야 합니다. 수 있는 응용 프로그램 코드의 부분을 이해 해야 동등한 또는 향상 된 기능이 MFC 2.0 클래스에서 파생 하 여 제거 합니다. 뿐만 아니라 것입니다 더 라이브러리 구현에 사용 하 여 작게 소스 코드, 하지만 그것은 만들 것입니다 응용 프로그램의 이러한 부분 더 MFC 프레임 워크의 나머지에 통합。
MFC 2.0 응용 프로그램을 완전히 마이그레이션하여 MFC에서 상대적으로 작은 추가 기능 파생 수 있을 것입니다 추가 비용. 예를 들어, 응용 프로그램 분할 창 사용자 인터페이스를 하지 않은 경우 하나를 사용자에 게 도움이 될 것 이라고 다음을 수 있을 것입니다 신속 하 게이 기능을 추가 하려면 코드 2.0 MFC 문서/뷰 아키텍처를 포팅 이미 데。
MFC 2.0 전체 마이그레이션 대형 응용 프로그램에 대 한 일 노력이 필요할 수 있습니다, 있지만 프로세스 자체는 상당히 간단 합니다. 다음과 같은 일반적인 단계를 프로세스 설명:
코드 편집을 시작 하기 전에 이렇게. 많은 프로그래머가 뷰 코드와 문서 코드를 꼬이는 경향이 있다. 비록 일을 그렇게 하지 반드시 "나쁜", 문서 및 뷰 기능 분리 MFC 프레임 워크를 지지 하 고 특히 잘 지원 하는 디자인 철학입니다. MFC 1.0 CDocument 및 CView 클래스 없 었 어 요, 비록 그것은 또한 문서/뷰 분리를 승인 했다. 그래서 라이브러리의 모든 미래의 버전을 것입니다。
CDocument 및 CView 클래스, 특히 MFC 자습서 샘플을 사용 하는 MFC 2.0 샘플 연구 낙서. 응용 프로그램 문서 고 보기는 결정을 분석. 다중 문서 형식 또는 조회 응용 프로그램에 있는지 여부 확인。
응용 프로그램 문서/뷰 분리를 지우려면 자체를 빌려 하지 않습니다 경우에 완전히 MFC 2.0 마이그레이션 프레임 워크의 본질적으로 완벽 한 활용을 수 여전히. 당신이 수 있는 "가짜" 문서/뷰 분리 CDocument-및 CView를 구현 하 여-파생 클래스, 하지만 문서 또는 보기 클래스는 다른 클래스에 작업의 대부분을 위임할 수 있습니다. 또는, 뷰 클래스 CFrameWnd-또는 CMDIChildWnd에 의존 수 있습니다-대부분의 응용 프로그램의 사용자 인터페이스를 구현 하는 클래스를 파생 합니다. 요약 하면, 당신은 거의 완전 한 자유 문서, 뷰 및 프레임 창 클래스를 분리 하는 방법。
귀하의 분석에 응용 프로그램 여러 뷰 클래스와 가능성이 여러 문서 클래스를 해야 하는지 결정 해야 합니다. 심지어 비교적 간단한 응용 프로그램 하나 이상의 뷰 클래스를 때때로 필요로 한다. 그러나, 분할자 창 에서처럼 여러 보기 하지 않습니다 반드시 쓰게 해야 여러 CView-클래스를 파생 합니다. 예를 들어, 분할 창의 각 창 분할 창에서 다른 창으로 동일한 사용자 인터페이스를 제공 하는 경우 동일한 뷰 클래스를 공유할 수 있습니다. 이 경우, 각 창 단순히 동일한 뷰 클래스의 고유한 개체입니다. 응용 프로그램이 다른 창에서 매우 독특한 사용자 인터페이스를 제공 하는 경우 아마도 여러 뷰 클래스 디자인을 원할 거 야。
AppWizard 뼈대 AppWizard 대화 상자에서 옵션으로 선택 하는 다양 한 프레임 워크 기능을 지 원하는 MFC 2.0 응용 프로그램을 만들 것입니다. 기초 응용 프로그램을 만드는 마법사를 실행 하기 전에 당신이 먼저 익숙해져야 AppWizard 제공 옵션。
그런 다음 마법사의 옵션을 선택 하려는 거 야 결정을 약간의 시간이 걸릴. Appwizard를 실행 하면 처음 몇 분 후에이 작업을 수행 하는 것을 시도 하지 마십시오. 예를 들어, 응용 프로그램이 OLE 지원 하지이 고려해 야 할 주요 결정 이다. 시작 하려면 마법사의 OLE 옵션을 선택 하지 않았다 아직도 MFC의 OLE 기능을 사용 하도록 응용 프로그램 코드를 수정할 수 있을 거 야. Appwizard에서 OLE 옵션을 시간을 절약할 것 입니다로 시작 하지만 시작。
귀하의 분석 응용 프로그램은 단일 문서 인터페이스 (SDI) 또는 다중 문서 인터페이스 (MDI) 응용 프로그램 여부를 결정 해야 합니다. 다른 Windows 응용 프로그램에서 이러한 두 가지 사용자 인터페이스에 친숙 하다 면 특정 결정이 분명해 야 합니다. AppWizard 만들어집니다 MDI 응용 프로그램 기본적으로 그것은 그들을 수 있습니다에 대 한 MDI 사용자 인터페이스는 일반적으로 최종 사용자에 게 더 많은 기능 한 문서/파일 보다는 더 많은 오픈 한 번에. 다행히도, MFC 2.0 문서/뷰 아키텍처와 함께 MDI 지원 필요 귀하의 부분에 추가 코딩 없이。
위의 분석을 할 데, 당신이 지금 응용 프로그램 뼈대 코드를 만들려면 마법사를 실행할 준비가。
문서, 뷰 및 프레임 창에 응용 프로그램을 분리 하는 방법을 분석 해야 좋은 생각이 어떤 이름 들은 해당 클래스와 모듈에 게 합니다. 자습서 샘플 CScribDoc 및 CScribView, scribdoc.cpp 및 같은 scribvw.cpp 다소 일반적인 이름을 할당할 수도 있습니다. 그러나 응용 프로그램에서 여러 개의 뷰 클래스를 필요한 경우 첫 번째 AppWizard 만든 뷰 클래스 CDataEntryView 및 Creportview와 같은 더 특수 한 이름을 주고 싶어합니다 아마. 여러 문서 및 뷰 클래스를 만드는 방법에 대 한 자세한 내용은 다음 단계를 참조 하십시오。
SDI 또는 MDI와 같은 원하는 및 OLE, 이제 해야 마법사 옵션을 선택 하 고 단지 몇 분 안에 기초 응용 프로그램을 만들 수 있게 추가 마법사 옵션을 예상 하는 데。
위의 분석 응용 프로그램 여러 보기, 문서, 또는 프레임 창 클래스가 있어야 결정 하는 경우 다음 그것 Appwizard를 실행 한 후에 이러한 클래스에 대 한 뼈대 코드를 바로 만들 수 있는 좋은 시간 이다。
Appwizard에서 생성 하는 것 들을 복제 하 여 추가 보기, 문서 및 프레임 창 클래스에 대 한 뼈대 코드를 만들 수 있습니다. 즉, 두 번째 문서 또는 클래스에 대 한 새 모듈 이름을 할당.cpp 및.h 파일을 복사 합니다. 다음 클래스 이름을 변경 하 여 뼈대 코드를 편집 합니다. 또 다른 대안은 Classwizard의 클래스 추가 기능을 사용 하 여 지정한 이름을 사용 하 여 지정한 파일에 자동으로 새로운 클래스를 만드는 것 이다. 이미 익숙한 Classwizard의 능력을 자유롭게 자습서를 수행한 경우 새 클래스를 만들 수 있을 것입니다.
두 경우 모두 CWinApp-파생 클래스의 InitInstance 함수를 만들려는 사이 여러 문서, 뷰 및 프레임 창 클래스는 모든 연결에 대 한 추가 문서 템플릿 개체를 등록 해야 합니다。
이것은 또한 빠른 단계입니다. 응용 프로그램에서 여러 문서, 뷰, 또는 프레임 창 클래스를 구현 하는 데 최선을 다하고 있다면이 단계를 연기할 수 있습니다.
이 단계는 MFC 1.0 응용 프로그램을 MFC 2.0 마이그레이션 작업의 대부분을 나타냅니다. 이 증분 수행 해야 합니다. 한 번에 응용 프로그램의 상대적으로 작은 덩어리를 마이그레이션하십시오. 이 처럼 프레임 워크를 제공 하는 기능 수 있습니다 오래 된 MFC 1.0 응용 프로그램 코드의 일부를 삭제 하는 방법에 대 한 자세한 내용은 배우게 될 거 야。
코드의이 덩어리를 마이그레이션할 때 마이그레이션 "최소"에서 제시 하는 지침을 명심에서 하십시오. 이러한 지침의 많은 전체 마이그레이션에 적용 됩니다. AppWizard 것입니다 이미 //{{AFX_MSG 및 //{{AFX_MSG_MAP 의견에 추가 명령 대상 클래스 (응용 프로그램, 문서, 뷰 및 프레임 창). 수동으로 최소한의 마이그레이션 방법 아래에서 이러한 추가 대 한 필요는 없습니다. 필요 하지 않지만 메시지 지도에 중첩 된 //{{AFX_MSG 코멘트 사이 메시지 처리 함수를 이동 하는 것이 좋습니다. 또한, 귀하의 헤더 파일에 //{{AFX_MSG 의견 간에 이러한 메시지 처리 (afx_msg) 함수의 선언 이동 합니다. 이렇게 하면 프로젝트의 life cycle(s)의 나머지 부분에 걸쳐 Classwizard를 사용 하 여。
//{{AFX_MSG 의견에 관한 이러한 권장 사항에도 적용, 아마도 대화를 정도. 주어진된 대화 상자 클래스에 많은 미래의 변화를 예측 하지 하는 경우 다음 그것 가치가 되지 않을 수도 귀하의 노력을 그 대화 Classwizard를 인식 합니다. 그건 괜 찮 아 요입니다. 좋습니다, 물론, Classwizard의 클래스 추가 옵션을 사용 하 여 모든 새 대화 상자 클래스 만들기。
MFC 1.0 또는 Windows 응용 프로그램을 마이그레이션할 때 기존 파일 형식과 호환성을 유지 하는 것이 좋습니다. (기본 MFC 2.0 문서 serialization 메커니즘 수 없습니다 응용 프로그램에 대 한 적절 한.) CFile 쓰기 및 읽기 호출 또는 비 파일을 구현 하려면 다음 웹 사이트를 기반으로 문서를 직접 할 CDocument::OnOpenDocument 와 OnSaveDocument를 재정의 합니다. MFC 일반 샘플 DIBLOOK 이 방법의 예를 제공 합니다. 다음이 문제가 되지 않을 것입니다 이미 당신의 현재 응용 프로그램 개체를 serialize 하는 경우。
알파벳 API 변경
이러한 변화에 대 한 이유를 이해 하려면를 참조 하십시오 "변경에 대 한 이유" 아래。
| API / 변수 | MFC 2.0 변경 (변경 사유) |
| CMetaFileDC::Close | 반환 형식 (2) |
| CWnd::Create | 추가 기본 매개 변수 추가, CWnd * const (1, 3) |
| CFrameWnd::Create | 추가 기본 매개 변수 추가, CWnd * const (1, 3) |
| CMDIChildWnd::Create | 추가 기본 매개 변수를 추가, CWnd * const (1, 3) nbsp; dwStyle 기본값은 지금: WS_CHILD (ko) | WS_VISIBLE (KO) | WS_OVERLAPPEDWINDOW(&N) |
| CWnd::CreateEx | 추가 기본 매개 변수 추가, CWnd * const (1, 3) |
| CBitmap::CreateBitmap | 매개 변수 형식 (4) |
| CDC::EnumObjects | 콜백 프로토 타입 (2) |
| CTime::Format | Const 함수 (3) |
| CTimeSpan::Format | Const 함수 (3) |
| CTime::FormatGmt | Const 함수 (3) |
| CFile::GetStatus | Nonvirtual (5) |
| CDC::GrayString | 콜백 프로토 타입 및 매개 변수 형식 (2) |
| CBitmapButton::LoadBitmaps | 추가 기본 매개 변수 (1) |
| CWnd::OnActivateApp | 매개 변수 유형 (2) |
| CWnd::OnCompareItem | 추가 매개 변수 (6) |
| CWnd::OnDeleteItem | 추가 매개 변수 (6) |
| CWnd::OnDrawItem | 추가 매개 변수 (6) |
| CWnd::OnDropFiles | 매개 변수 유형 (2) |
| CWnd::OnGetMinMaxInfo | 매개 변수 형식 (6) |
| CWnd::OnMeasureItem | 추가 매개 변수 (6) |
| CWnd::OnMenuChar | 반환 형식 (2) |
| CWnd::OnNcCalcSize | 추가 매개 변수 (6) |
| CWnd::OnPaintClipboard | 매개 변수 유형 (2) |
| CWnd::OnParentNotify | 매개 변수 유형 (2) |
| CWnd::OnSizeClipboard | 매개 변수 유형 (2) |
| CWnd::OnSysCommand | 매개 변수 유형 (2) |
| CWnd::OnWinIniChange | 매개 변수 유형 (2) |
| CDC::PlayMetaFile | 매개 변수 유형 (2) |
| CEdit::SetSel | 추가 기본 매개 변수 (6) |
| CEdit::SetTabStops | 매개 변수 유형 (5) |
| CWnd::SetTimer | 콜백 프로토 타입 및 매개 변수 형식 (2) |
| CRuntimeClass::m_pszClassName | 이름이 바뀐된 m_lpszClassName (5) |
| 삭제 되거나 사용 되지 않는 API | MFC 2.0 변경 (변경 사유) |
| CBitmapButton | 매개 변수 3-제거 ctor 사용 LoadBitmaps (1) |
| CMDIFrameWnd:: CreateClient | OnCreateClient (1)를 사용 하 여 |
| GetChildFrame | MDIGetActive (1)를 사용 하 여 |
| GetDCOrg | Windows API를 사용 하 여 직접 3.x (4)에 대 한 |
| m_pMDIFrameWnd | 지금 전화 GetParentFrame 또는 GetMDIFrame (1) |
변경 내용에 대 한 이유:
컴파일러 오류
MFC 2.0 Api에 대 한 대부분의 변경 내용은 모든 표준 형식 변환은 컴파일러를 만족 하는 경우 몇 가지 컴파일러 오류 또는 없음 중 하나을 생성 됩니다. MFC 2.0에서 기존 MFC 1.0 응용 프로그램을 컴파일할 때 다음 컴파일러 오류를 생성 될 수 있습니다.:
| 번호 | 컴파일러 오류 메시지 |
| 컴파일러 오류 C2039 | 'Identifier': ' 클래스 키 '의 구성원이 아닙니다 |
| 이 오류가 발생 하면 멤버 함수 또는 예를 들면 CFrameWnd m_pMDIFrameWnd 클래스에서 데이터 멤버를 제거。 | |
| 컴파일러 오류 C2501 | 'Identifier': decl 지정자를 누락。 |
| 이 오류는 알 수 없는 클래스 이름을 사용 하는 경우에 발생 합니다. 이 때 일반적으로 경우 클래스는 더 이상 존재 또는 다른 헤더 파일을 이동 했습니다. 예를 들어 CMetaFile 그리고 CBitmapButton 에 대 한이 오류를 얻을 경우 추가 해야 합니다에 대 한 # include "afxext.h" 이러한 클래스를 사용 하 여 소스 파일을。 | |
| 컴파일러 오류 C2248 | '회원' 'class' 클래스에 선언 된 '지정자' 멤버에 액세스할 수 없습니다. |
| 멤버의 액세스 2 MFC 1.0에서 변경 된 경우이 오류가 발생 합니다. 예를 들어, 문서화 되지 않은 API 공개 에서 멤버 액세스 보호 로 이동 되었습니다. 이 적절 한 MFC 2.0 기능을 사용 하도록 변경 해야 하는 문서화 되지 않은 및 지원 되지 않는 Api를 사용 하는 코드에서 발생 한다。 | |
| 컴파일러 오류 C2642 | 회원에 관련 된 포인터에서 캐스트 멤버에 대 한 포인터를 해야。 |
| 메시지 처리기 함수 프로토타입을 afxwin.h에 하나에서 다릅니다 경우이 오류가 발생 합니다. 예를 들어, ON_WM_ACTIVATEAPP 매크로 포함 하는 줄 매개 변수 및 OnActivateApp 메시지 처리기의 반환 형식이 일치 하는 MFC 1.0 선언 하는 경우이 오류를 방출 한다。 | |
| 컴파일러 오류 C2660 | 'Function': 함수 '번호' 매개 변수를 받지 않습니다。 |
| 매개 변수 개수는 MFC 1.0에서 MFC 2.0 변경 되었습니다. 예를 들어에이 오류 발생 세 개의 매개 변수를 가진 CBitmapButton 생성자 호출 이후이 특정 생성자는 제거 하 고 교체 LoadBitmaps 멤버 함수。 | |
| 컴파일러 오류 C2664 | 'Function': 매개 변수 '번호' 'type1'에서 'type2'로 변환할 수 없습니다 |
| 매개 변수 유형을 변경 하 고 표준 변환 컴파일러를 만족 하지 않는. CDC::EnumObjects 이 한 예입니다. 이 경우에 콜백 함수 프로토타입을 변경 되었습니다. |
기술 노트 번호로 |nbsp; 카테고리별 기술 노트(&N)