TN019: การปรับปรุงที่มีอยู่ MFC โปรแกรม MFC 3.0

หมายเหตุทางเทคนิคนี้ให้แนวทางสำหรับโปรแกรมประยุกต์ MFC 1.0 ย้ายเครื่องมือ MFC 2.0 เป็นหลัก MFC 2.0, 2.5 และ 3.0 เพิ่มเติมแตกต่างถูกนำเสนอในส่วนแรก ด้านล่าง?

MFC 4.0/3.0 API การเปลี่ยนแปลง

ไม่มีการเปลี่ยนแปลงไม่รู้จักการ APIs MFC มีการระบุไว้ที่อาจทำให้รหัสที่มีอยู่แล้วต้องการเปลี่ยนแปลง มี หลักสูตร เพิ่มเติมคุณลักษณะต่าง ๆ ที่คุณอาจต้องการใช้ประโยชน์ของ ดูข้อมูลเพิ่มเติมเกี่ยวกับคุณลักษณะต่าง ๆ เหล่านี้Visual c ++ Programmer ของรายการแนะนำ?

API MFC 2.5 มีการเปลี่ยนแปลง

MFC 2.5 เพิ่มคุณลักษณะหลักสองในไลบรารีคลาส: OLE 2.0 สนับสนุน ซึ่งแทนสนับสนุน OLE 1.0 และสนับสนุน ODBC ซึ่งให้การเข้าถึงฐานข้อมูล เจตนาของ technote นี้ครอบคลุมการเปลี่ยนแปลงของ API ที่อาจมีผลต่อโค้ดที่มีอยู่ของคุณได้ สำหรับข้อมูลเกี่ยวกับคุณลักษณะใหม่เหล่านี้ ไม่ครอบคลุมในนี้ technote ดูคู่มือ Visual c ++ Programmer ของ?

CFrameWnd::RecalcLayoutมีการเพิ่มเติมพารามิเตอร์ BOOL bNotify ระบุว่า OLE เซิร์ฟเวอร์ใด ๆ การแจ้งให้ทราบหรือไม่ว่าพวกเขามีการเปลี่ยนแปลงเค้าโครง มันจะเป็นจริงโดยปกติ และดัง นั้นที่เป็นค่าเริ่มต้น ฟังก์ชันนี้เป็นเสมือน ดังนั้นหากโปรแกรมของคุณมีตัวแทนของฟังก์ชันนี้ คุณจำเป็นต้องเพิ่มพารามิเตอร์เพิ่มฟังก์ชันของคุณเช่นกัน?

ไม่มีการเปลี่ยนแปลงอื่น ๆ ทำให้ฟังก์ชันอย่างชาญฉลาดในไลบรารี MFC 2.5 สนับสนุน OLE 2.0 เป็น ODBC ถ้าโปรแกรมของคุณใช้อย่างชาญฉลาด MFC APIs คุณควรตรวจทานใช้เช่นทั้งหมดเพื่อให้แน่ใจว่า พวกเขายังคงถูกต้อง?

กำลังโยกย้าย MFC 1.0 โปรแกรมประยุกต์ MFC 2.0

สิ่งสำคัญ: การทำความเข้าใจ และประเมินวิธีสองที่แสดงด้านล่าง คุณต้องคุ้นเคยกับแนวคิดเกี่ยวกับ MFC 2.0 เช่นเอกสารและมุมมองสถาปัตยกรรม และเครื่องมือ เราขอแนะนำให้คุณทำงานอย่างน้อยผ่านตัวอย่างบทช่วยสอนเกี่ยวกับ MFC เขียนในบทช่วยสอนก่อนที่จะเริ่มต้นการโยกย้ายของรหัสที่มีอยู่?

มีวิธีพื้นฐานที่สองการโยกย้ายอยู่ประยุกต์จาก MFC รุ่น 1 เปิดตัว Microsoft C7 การ MFC รุ่น 2?

การโยกย้ายที่น้อยที่สุด

คุณใช้วิธีการ "น้อย Migration" ทำเฉพาะแปลงขั้นต่ำที่จำเป็น ดังนั้น:

• โปรแกรมประยุกต์ที่มีอยู่ของ MFC 1.0 compiles และเชื่อมโยงกับไลบรารี MFC 2.0 เรียบร้อยแล้ว?
  
  
• ทรัพยากรของคุณสามารถแก้ไขเรียบร้อยแล้วได้ใช้ Visual c ++?
  
  
• ฟังก์ชันการจัดการข้อความและการโต้ตอบข้อมูลของคุณจะรับรู้ โดย ClassWizard?

นี่คือวิธีการที่ง่ายที่สุด แต่นอกจากนี้จะไม่ใช้ประโยชน์จากคุณลักษณะในไลบรารี MFC 2.0 แม้ว่าคุณเลือกวิธีการ "เต็ม Migration" คุณจะต้องทำความเข้าใจ และการออกกำลังกายเทคนิคสำหรับการโยกย้ายที่น้อยที่สุด?

โยกย้ายเต็มรูปแบบ

ถ้าคุณทำการ "เต็ม Migration" คุณสามารถใช้ประโยชน์จากไลบรารี MFC 2.0 ใช้วิธีการโยกย้ายที่น้อยที่สุด คุณจะสามารถแก้ไขโปรแกรมประยุกต์ของคุณโดยใช้ Visual c ++และ ClassWizard โดยใช้วิธีการโยกย้ายเต็มรูปแบบ เข้าสนับสนุน MFC 2.0 ดังต่อไปนี้:

• อินเทอร์เฟซมาตรฐานไฟล์เมนูและโต้ตอบผู้ใช้สำหรับงาน คุณได้รับคุณลักษณะเช่นไฟล์มาตรฐานเปิด และบันทึกในกล่องโต้ตอบ file manager ลาก และปล่อย - ใช้ล่าสุดการติดต่อกับเมนูแฟ้ม และอื่น ๆ?
  
  
• การพิมพ์ คุณใส่รหัสมุมมอง ไลบรารีจะดูแลรับเครื่องพิมพ์ DC ย้ายขึ้นยกเลิกการโต้ ตอบ การทำงานวนรอบการพิมพ์ และอื่น ๆ?
  
  
• ตัวอย่างก่อนพิมพ์ โดยปกติแล้ว คุณจะต้องทำไม่เขียนโค้ดพิเศษ มีฟังก์ชันตัวอย่างก่อนพิมพ์ในโปรแกรมประยุกต์ของคุณ?
  
  
• แถบเครื่องมือและแถบสถานะ พวกเขาก็ง่ายต่อการเพิ่มให้กับโปรแกรมประยุกต์ของคุณโดยใช้ Visual c ++และ MFC 2.0?
  
  
• แยก windows ถ้าคุณจัดโครงสร้างรหัสแสดงผลของคุณลงในมุมมองคลา แล้วคุณจะสามารถแสดงผลใน windows แยกค่าใช้จ่ายเพิ่มเติมเพียงเล็กน้อยมาก?
  
  
• การสนับสนุน OLE2 โดยใช้สถาปัตยกรรม "เอกสาร/มุมมอง" โปรแกรมประยุกต์ของคุณสามารถคงจะ OLE ที่เปิดใช้งาน โดยไม่มีการทำงานจำนวนมาก?

วิธีการโยกย้ายโดยรวมทั้งหมดเป็นการ จำลองการพัฒนาโปรแกรมประยุกต์ MFC 2.0 ตั้งแต่และส่วนประกอบ การเริ่มต้น ด้วย AppWizard ความแตกต่างจากการพัฒนาโปรแกรมประยุกต์ MFC 2.0 ตั้งแต่ แน่นอน ไม่ว่า คุณจะขอยืมมากที่คุณเขียนในขณะที่เหมาะสม.รหัส MFC 1.0?

การโยกย้ายที่น้อยที่สุด

ต่อไปจะนำเสนอรายละเอียดแนวทางสำหรับการปฏิบัติการโยกย้ายที่น้อยที่สุด?

ตามนโยบาย Windows 3.1 จำกัด typedefs

เริ่มต้นสร้างของ 2.0 MFC ในไลบรารีที่ยึดตามการ typedefs Windows 3.1เคร่งครัดซึ่งมีอธิบายใน Windows 3.1 SDK MFC 1.0 มีเคร่งครัดปิด แต่ MFC 2.0 ได้เคร่งครัดเปิดตามค่าเริ่มต้น นี้เป็นไปตามความมุ่งมั่นของ MFC เพื่อติดตาม API ของ Windows มาตรฐานอุตสาหกรรม และบุญธรรมแนวปฏิบัติด้านการพัฒนาที่ทำการพัฒนาโปรแกรมประยุกต์มีเสถียรภาพที่ง่ายขึ้น เช่นเดียวกับ typedefsเคร่งครัดได้เป็นประโยชน์กับนักพัฒนาของคลาสที่ MFC 2.0 ในการผลิตซอฟต์แวร์ที่สมบูรณ์ ดังนั้นที่จะเป็นจริงสำหรับคุณในการพัฒนาโค้ดโปรแกรมประยุกต์ของคุณ?

เมื่อใช้ชนิดการเคร่งครัดที่ตรวจสอบครั้งแรก ข้อผิดพลาดในการคอมไพล์จำนวนมากจะปกติทำ การปรับเปลี่ยนโปรแกรมประยุกต์ของคุณ MFC 1.0 คล้องกับ Windows 3.1เคร่งครัดtypedefs อาจดีแสดงจำนวนมากของคุณพยายามย้ายที่น้อยที่สุด?

เมื่อโปรแกรมประยุกต์ของคุณสอดคล้องกับเคร่งครัดคุณอาจต้องการคอมไพล์แฟ้มปฏิบัติการกับการเปลี่ยนแปลง ตัวอย่างเช่น ตัวอย่าง ABOUT2 และ FILEVIEW MFC 1.0 คอมไพล์ ด้วยไม่มีการเปลี่ยนแปลงเพิ่มเติม ได้เรียบร้อยแล้วเคร่งครัดสอดคล้องกับมาตรฐาน และไม่ได้ไม่มีใช้ใด ๆ เปลี่ยน MFC APIs?

MFC 2.0 API การเปลี่ยนแปลง

นอกเหนือจากตามนโยบายเคร่งครัดส่วนใหญ่ไม่ต้องทำการโยกย้ายที่น้อยที่สุดคือการ ระบุ และเปลี่ยนรหัสที่โปรแกรมประยุกต์ของคุณสอดคล้องกับการเปลี่ยนแปลงของ MFC 2.0 API ค่อนข้างน้อย?

ตกกว่า 1800 MFC 1.0 APIs, 20 เท่าของ APIs ที่มีการเปลี่ยนแปลงผลลัพธ์ในข้อผิดพลาดขณะคอมไพล์ การเปลี่ยนแปลงเหล่านี้จำเป็นต้องแก้ไข trivial เท่าที่มีอยู่ MFC 1.0 โปรแกรมประยุกต์ การเปลี่ยนแปลงที่กว้างขวางมากที่สุดคือการ จัดโครงสร้างการสถาปัตยกรรมใหม่ของคลาสที่ OLE การเปลี่ยนแปลงเหล่านี้ครอบคลุมในด้านเทคนิคหมายเหตุ 18?

การคาดการณ์ที่เปลี่ยนแปลงที่คุณจำเป็นต้องตรวจ ให้ดูส่วน "อักษรเปลี่ยน API แปลง" ที่ส่วนท้ายของ technote นี้ และมีประโยชน์ ย่อสรุปที่ MFC 1.0 APIs ถูกปรับเปลี่ยนใน MFC 2.0?

ถ้าคุณไม่เปลี่ยนแปลงทั้งหมดจำเป็นในการจัดการกับรหัส MFC 2.0 คุณจะได้รับคอมไพล์และข้อผิดพลาดการเชื่อมโยงต่าง ๆ เกือบทุกง่ายต่อการวิเคราะห์ข้อผิดพลาดเหล่านี้ได้ เพื่อช่วยในการวินิจฉัยโรคของคุณ เรามีแนวทางในส่วน "คอมไพเลอร์ผิด" ที่ส่วนท้ายของ technote นี้?

APIs MFC ดังต่อไปนี้จะถูกเอาออกใน MFC 2.0 เราขอแนะนำ APIs ทางเลือกที่เหมาะสม รายการนี้ไม่รวมการเปลี่ยนแปลงการใช้งานอย่างชาญฉลาด APIs?

CDC::GetDCOrg

ไม่มีGetDCOrgใน Win32 สำหรับโปรแกรมประยุกต์การเฉพาะของ Windows 3.x เพียงเรียก Windows API :: GetDCOrgโดยตรง?

CRuntimeClass::m_pszClassName

ตัวแปรนี้สมาชิกขณะนี้คือ การLPSTRแทนหน่วยความจำแบบจำลองขึ้น (char *) มันมีชื่อว่าm_lpszClassNameใน MFC 2.0?

CMDIChildWnd::m_pMDIFrameWnd

ใน MFC 1.0 ตัวแปรนี้สมาชิกชี้ไปคลา MDIFrame แม่ ตัวแปรนี้สมาชิกถูกแทนที่ ด้วยฟังก์ชันสมาชิกCMDIChildWnd::GetMDIFrame ถ้าคุณกำลังใช้หลายเอกสารติดต่อ (MDI) ใน MFC 2.0 ส่วนใหญ่ใช้CMDIChildWnd::m_pMDIFrameWnd (หรือGetMDIFrame) ซึ่งไม่จำเป็นเนื่องจากการสนับสนุน MDI เริ่มต้นจับทั้งหมดของคำสั่งเมนู MDI Windows มาตรฐาน?

CFrameWnd::GetChildFrame

ใช้CMDIFrameWnd::MDIGetActiveสำหรับเฟรม MDI แทน?

API แบบต่อไปนี้ได้ถูกปล่อยไว้ใน MFC 2.0 เพื่อสนับสนุนความเข้ากันได้ที่ 1 แต่ล้าสมัย มันจะถูกเอาออกจาก MFC รุ่นในอนาคต?

CMDIFrameWnd::CreateClient

ฟังก์ชันการทำงานนี้ได้ถูกแทนที่ โดยกลไกOnCreateClientทั่วไปที่สนับสนุนการสร้างมุมมองและการสนับสนุน MFC 2.0 MDI ต้นฉบับCreateClientคุณยังคงสามารถใช้สำหรับโปรแกรมประยุกต์ MDI ที่จัดการตนเอง MDI เฟรมของหน้าต่างเมนูบาร์ (โดยใช้CMDIFrame::MDISetMenu) การสนับสนุน MFC 2.0 MDI จะสลับแถบเมนูของ MDI กรอบหน้าต่างโดยอัตโนมัติไปยังเมนูสำหรับหน้าต่างลูก MDI ในปัจจุบันที่ใช้งานอยู่?

เปลี่ยนแปลงอื่น ๆ ที่เกี่ยวข้องกับ API

MFC ชั้นที่สองถูกย้ายจาก afxwin.h ส่วนหัวของแฟ้ม afxext.h:

• CBitmapButton
  
  
• CMetaFileDC

เพิ่มในแฟ้มของคุณ.cpp ที่อ้างอิงชั้นเหล่านี้ต่อไป:

#รวม lt;afxext.h>

มีการเปลี่ยนแปลงหลาย APIs เพื่อให้พวกเขา stricter เกี่ยวกับการใช้ตัวปรับแต่งการ 'const' การเปลี่ยนแปลงเหล่านี้มีผลใช้ชื่อชนิด LPCSTR และพิมพ์ชื่อใหม่ของ LPCRECT สอดคล้องกันมากขึ้น หมายเหตุ มีปัญหาเวลาคอมไพล์ไม่มีการเปลี่ยนแปลงเหล่านี้ ตั้งแต่ชนิดใดก็สามารถจะเลื่อนไปรุ่น const ชนิดที่เมื่อใช้เป็นอาร์กิวเมนต์ เช่นเดียวกับการเปลี่ยนแปลงที่เคร่งครัดนี้ทำให้รหัสที่มีเสถียรภาพมากขึ้นเมื่อ const ข้อมูลตัวชี้ใช้รหัสของคุณ?

ฟังก์ชันสร้างหน้าต่างด้านล่างมีพารามิเตอร์เพิ่มเติมมี แต่เนื่องจากพารามิเตอร์ล่าสุดมีค่าเริ่มต้นของค่า NULL รหัสที่มีอยู่จะทำงาน โดยไม่มีการปรับเปลี่ยน ฟังก์ชันเหล่านี้ได้

• CWnd::Create
  
  
• CFrameWnd::Create
  
  
• CMDIFrameWnd::Create
  
  
• CMDIChildWnd::Create

ฟังก์ชันต่อไปนี้เป็นเสมือนใน MFC 1.0 แต่ตอนนี้เป็น nonvirtual ใน MFC 2.0:

• CFile::GetStatus
  
  
• CFrameWnd::GetParentFrame

ถ้าอย่างใดอย่างหนึ่งเหล่านี้ฟังก์ชันแทนคลาสที่ได้รับของโปรแกรมประยุกต์ของคุณ MFC 1.0 ไม่น่าที่จะเรียกฟังก์ชันในชั้นเรียนของคุณได้รับใน MFC 2.0 นอกจากนี้GetParentFrameถูกย้ายจากCFrameWndไปCWndมี API มีประโยชน์มากโดยทั่วไป?

สมาชิกทั้งหมดคงเรียน รวมทั้งฟังก์ชันตัวดำเนินการสากล/เพื่อน ตอนนี้ยึดตามปาสกาลข้อตกลงในการโทร ฟังก์ชันทั้งหมดที่ส่วนกลางได้AFXAPI (PASCAL) อีก นี้ไม่เป็นปัญหาเวลาคอมไพล์ แต่ทำให้เร็วขึ้น และมีขนาดเล็กลงสร้างรหัส?

หลายชั้นเดียวใช้งานและโครงสร้างได้ถูกเปลี่ยนชื่อเพื่อไม่ให้ใช้คำนำหน้า 'C' ตัวอย่างเช่นCExceptionContextถูกเปลี่ยนชื่อให้AFX_EXCEPTION_CONTEXT เรียนเหล่านี้เป็นเอกสาร และรายละเอียดการใช้งานของไลบรารีคลาสยังคงอยู่ ไม่น่าว่า คุณมี relied เหล่านี้ และขอโดยทั่วไปแนะนำว่า คุณไม่พึ่ง APIs อย่างชาญฉลาดของไลบรารีคลาสเนื่องจากพวกเขาสามารถเปลี่ยนแปลงในรุ่นในอนาคต?

เปลี่ยนลักษณะการทำงานเริ่มต้นของ MFC 2.0

จัดการกับการเปลี่ยนแปลงของ MFC API เป็นเรื่องง่าย ด้วยความช่วยเหลือของข้อผิดพลาดที่รายงาน โดยคอมไพล์เลอร์และตัวเชื่อมโยง การเปลี่ยนแปลงในไลบรารีทั้งหมดไม่ได้เห็นในส่วนหัวของแฟ้มไลบรารี อย่างไรก็ตาม เปลี่ยนแปลงบางอย่างจะเปิดเผยในการทำงานของเวลาทำงานของโปรแกรมประยุกต์ของคุณ การเปลี่ยนแปลงเหล่านี้ได้โดยทั่วไปจะไม่กระดูก ตราบใดที่คุณคาดว่าจะได้ ข้อมูลต่อไปนี้ให้ไว้เพื่อช่วยคุณคาดว่าจะมีการเปลี่ยนแปลงเช่น behavioral?

CDialogและCModalDialogได้ถูกผสานเข้าไปในชั้นเดียว CModalDialogเดี๋ยวนี้ถือเป็นคลาสล้าสมัย อย่างไรก็ตาม MFC 1.0 ได้ อ้างอิงทั้งหมดไปยังCModalDialogจะยังคงถูกต้องผ่านทางโคโยกย้ายใน afxwin.h:

#กำหนด CModalDialog CDialog

สำหรับโปรแกรมประยุกต์จำนวนมากของ MFC 1.0 กำหนดนี้#วิก็เพียงพอ อย่างไรก็ตาม ไม่มีกรณีที่กำหนดนี้#ไม่เพียงพอ?

ถ้าคุณใช้กล่องโต้ตอบสร้าง และ relied ในลักษณะ "ทำอะไร" เริ่มต้นสำหรับOnOKและOnCancelแล้วคุณต้องแทนเหล่านี้และการทำงานเริ่มต้น เนื่องจากพวกเขาเรียกEndDialog (สำหรับการประมวลผลการโต้ตอบโมดอล) ขณะนี้?

นอกจากนี้CDialog::CreateIndirectยังสร้างกล่องโต้ตอบสร้าง เมื่อต้องการสร้าง กล่องโต้ตอบโมดอลใช้CDialog::InitModalIndirectแทนที่เอาCModalDialog::CreateIndirect API?

โต้ตอบข้อความและกล่องกล่องสีพื้นหลังในขณะนี้สามารถทั่วโลกตั้งใช้CWinApp::SetDialogBkColor API พารามิเตอร์เริ่มต้นตั้งค่าสีเทาอ่อน (ไม่COLOR_BTNFACE) เพื่อสร้างพื้นหลังสีเทา คุณอาจระบุสีอื่น ๆ?

ถ้าSetDialogBkColorไม่ได้ถูกเรียกในCWinAppของคุณ-มาInitInstanceฟังก์ชัน พื้นหลังหน้าต่างสี (ตั้งค่าในแอปเพล็ตควบคุมสี) จะใช้ค่าเริ่มต้น?

ใน MFC 1.0 ถ้า DLL มีอยู่ในวัตถุCWinAppมันเป็นความจำเป็นเพื่อให้การDllMainที่รวมอยู่ในการเรียกไปยังAfxWinTerm MFC 2.0 ให้นี้DllMainรหัสเพิ่มเติมใด ๆ ดังนั้นที่รวมอยู่ในการDllMainของคุณควรสามารถโยกย้าย DLL CWinApp::ExitInstanceสมาชิกฟังก์ชัน?

CMDIChildWnd::Createตอนนี้อย่างถูกต้องใช้พารามิเตอร์dwStyle ขณะนี้คุณต้องระบุลักษณะหน้าต่างเสร็จสิ้นสำหรับหน้าต่างลูก MDI ถ้าคุณระบุdwStyle = 0 คุณจะได้รับความล้มเหลวASSERTได้ตอนนี้ในCMDIChildWnd::PreCreateWindow เมื่อต้องการหลีกเลี่ยงปัญหานี้ คุณควรระบุลักษณะ WS_CHILD | WS_VISIBLE | WS_OVERLAPPEDWINDOW จะ เข้ากันได้แบบย้อนหลังกับ MFC 1.0?

MFC 2.0 รองรับการตั้งค่าลักษณะที่แตกต่างกันสำหรับ windows ลูก MDI ดังนั้นคุณสามารถลบตัวควบคุมหน้าต่างเฟรม บางถ้าต้อง?

คลาCFrameWndมีสมาชิกเป็นข้อมูลใหม่ BOOL CFrameWnd::m_bAutoMenuEnable ถูกตั้งค่าเป็น TRUE ตามค่าเริ่มต้น นี้ทำให้รายการเมนูที่ไม่มีตัวจัดการON_UPDATE_COMMAND_UIหรือON_COMMANDจะปิดใช้งานโดยอัตโนมัติ รายการเมนูที่มีตัวจัดการON_COMMANDแต่ไม่มีตัวจัดการON_UPDATE_COMMAND_UIจะถูกเปิดใช้โดยอัตโนมัติ?

นี้ช่วยให้คุณสามารถใช้คำสั่งเพิ่มเติมที่ยึดตามสิ่งที่เลือกปัจจุบัน ยัง นี้มากลดความต้องการโปรแกรมประยุกต์ที่เขียนตัวจัดการON_UPDATE_COMMAND_UIสำหรับเปิด/ปิดการใช้รายการเมนู ตัวอย่าง แอปพลิเคชันที่สร้างโดย AppWizard จะมีการแก้ไขตัด/คัดลอก/วางปิดการใช้งานจนกระทั่งโปรแกรมเมอร์ที่ใช้ตัวจัดการสำหรับพวกเขา?

อย่างไรก็ตาม ถ้าโปรแกรมประยุกต์ของคุณ MFC 1.0 ไม่ปรับปรุงการใช้ON_COMMANDและตัวจัดการON_UPDATE_COMMAND_UIแล้วมันต้องล้างm_bAutoMenuEnableอย่างชัดเจน มิฉะนั้น เมนูที่คุณปิดใช้งานจะสามารถสามารถโดยอัตโนมัติ?

การเปลี่ยนแปลงโครงการ (Build)

คุณสามารถสร้างโปรแกรมประยุกต์ MFC 1.0 makefile เป็นมาตรฐานการใช้ โดยวิธีที่ง่ายในการโยกย้ายโครงการของคุณคือการ ใช้สิ่งอำนวยความสะดวกโครงการของ Visual c ++การรักษา depedencies ของคุณและเลือกโครงการอื่น ๆ ภายในสภาพแวดล้อม Visual c ++?

มีข้อผิดพลาดการเชื่อมโยงทั่วไปคือ ไม่ได้แก้ไข externals ไป COMDLG32DLL และ SHELL32DLL APIs ให้แน่ใจว่าการเชื่อมโยงกับ COMDLG32LIB และ SHELL32LIB?

คุณอาจไม่สามารถปรับปรุงสร้างครั้ง โดยวาง#รวม lt;afxwin.h > ในส่วนหัวก่อนคอมไพล์ ตามแบบแผน MFC 2.0 แอปพลิเคชันระบุ "stdafx.h" เป็นหัวข้อก่อนคอมไพล์ โมดูล stdafx.cpp มี stdafx.h แล้ว เทคนิคนี้มีภาพประกอบ ด้วยรหัสสร้างขึ้น โดย AppWizard และหลายตัวอย่าง MFC 2.0?

หมายเหตุnbsp  ก็สำคัญว่า คุณไม่กำหนด หรือไม่กำหนดของแมโครใน _AFX_NO_XXX stdafx.h ดูบทความฐานความรู้ " PRB: ปัญหาเกิดขึ้นเมื่อทำการกำหนด _AFX_NO_XXX. " คุณสามารถค้นหาบทความ Knowledge Base บนซี ดีที่ไลบรารี MSDN หรือ http://www.microsoft.com/kb/(&N)?

Visual c ++และความเข้ากันได้ของ ClassWizard

แม้แต่สำหรับการโยกย้ายที่น้อยที่สุด เราขอแนะนำให้ คุณปฏิบัติตามขั้นตอนด้านล่างเพื่อให้คุณสามารถใช้งาน Visual c ++และ ClassWizard เพื่อแก้ไขทรัพยากรโปรแกรมประยุกต์ของคุณและรหัส?

• สำหรับโมดูลต่างๆ แผนที่ซึ่งข้อความที่คุณต้องการแก้ไขกับ ClassWizard เพิ่มข้อคิดเห็นสองบรรทัดต่อไปนี้ในแฟ้มของคุณ.cpp ภายนอกใช้งานฟังก์ชันใด ๆ:

  //{{AFX_MSG_MAP (lt ชื่อคลา >)
  //}}AFX_MSG_MAP
  

  lt ชื่อคลา > คือชื่อของระดับชั้นของคุณประกอบด้วยการแมปข้อความ?

  ในทำนองเดียวกัน เพิ่มข้อคิดเห็นสองบรรทัดต่อภายในของการประกาศคลาสที่สอดคล้องกันในแฟ้มของคุณ.h:

  //{{AFX_MSG (lt ชื่อคลา >)
  //}}AFX_MSG
  

  สำหรับตัวอย่างของประกาศเหล่านี้ มีลักษณะที่บรรทัดข้อคิดเห็นเดียวกันในโปรแกรมประยุกต์ที่สร้างขึ้น โดย AppWizard สำหรับคำอธิบายเกี่ยวกับข้อความบรรทัดข้อคิดเห็นเหล่านี้หมาย ความ ดู MFC: ใช้แฟ้มต้นฉบับ MFCในVisual c ++ Programmer ของคำแนะนำ?

• โครงการของคุณต้องมี makefile ที่ชื่อ lt โครงการ > .mak และแฟ้มทรัพยากรชื่อว่า <project>.rc, <project>ที่เป็นชื่อของโครงการของคุณ แฟ้มเหล่านี้ทั้งสองต้องอยู่ในไดเรกทอรีรากของโครงการ ที่ได้หมากแฟ้มอาจมี makefile ภายนอก?
  
  
• เรียกใช้ ClassWizard จากภายใน Visual c ++ เมื่อ ClassWizard พบที่เป็นไม่พบแฟ้ม CLW จะถามคุณว่า คุณต้องการสร้างอย่างใดอย่างหนึ่ง ตอบ 'ใช่' ที่ได้CLW แฟ้มอยู่และจำเป็นอย่างยิ่งแฟ้มดัชนีที่ใช้ระบุโมดูลที่มีบรรทัดข้อคิดเห็นเช่น //{{AFX_MSG ClassWizard?
  
  
• สำหรับโมดูลต่าง ๆ ฟังก์ชันเสมือนที่คุณต้องการแก้ไขกับ ClassWizard เพิ่มข้อคิดเห็นสองบรรทัดต่อภายในของคุณประกาศคลาสในแฟ้มของคุณ.h:

   //{{AFX_VIRTUAL (lt ชื่อคลา >)
  //}}AFX_VIRTUAL
  

โยกย้ายเต็มรูปแบบ

การโยกย้ายเต็มของคุณ C หรือ MFC 1.0 ประยุกต์ที่มีอยู่เพื่อ MFC 2.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 ที่ค่อนข้างน้อยต้นทุนพิเศษ ตัวอย่างเช่น ถ้าโปรแกรมประยุกต์ของคุณไม่มีอินเทอร์เฟซสำหรับผู้ใช้แยกหน้าต่าง แต่อย่างใดอย่างหนึ่งจะเป็นประโยชน์กับผู้ใช้ของคุณ แล้วคุณจะสามารถคุณลักษณะนี้ เพิ่มอย่างรวดเร็วมี ported MFC 2.0/มุม มองเอกสารสถาปัตยกรรมรหัสของคุณเรียบร้อยแล้ว?

แม้ว่าการโยกย้ายเต็มไป MFC 2.0 อาจต้องสองสามวันความพยายามสำหรับแอปพลิเคชันขนาดใหญ่ กระบวนการจะค่อนข้างตรงไปตรงมา ขั้นตอนทั่วไปดังต่อไปนี้อธิบายถึงกระบวนการ:

1. วิเคราะห์ factors วิธีของสถาปัตยกรรมของโปรแกรมประยุกต์ที่มีอยู่ลงในเอกสาร มุมมอง และกรอบ windows?

   ทำเช่นนี้ก่อนที่จะเริ่มแก้ไขรหัสใด ๆ โปรแกรมเมอร์มากมัก intertwine รหัสเอกสาร ด้วยรหัสของมุมมอง แม้ว่าการดำเนินการนี้จึงไม่จำเป็นต้อง "เสีย" แยกของเอกสารและดูฟังก์ชันคือ ปรัชญาการออกแบบที่กรอบ MFC endorses และสนับสนุนอย่างดีโดยเฉพาะอย่างยิ่ง แม้ว่า MFC 1.0 ไม่มีชั้นเรียนที่CDocumentและCViewมันยังรับรองแยกมองเอกสาร ดังนั้น จะทุกรุ่นในอนาคตของไลบรารี?

   ศึกษาตัวอย่าง MFC 2.0 ที่ใช้CDocumentและCViewชั้น โดยเฉพาะอย่างยิ่งการ MFC สอนอย่าง เขียน แล้ว วิเคราะห์โปรแกรมประยุกต์ของคุณเพื่อตรวจสอบว่าเอกสารคืออะไรและมุมมองคือ ตรวจสอบว่า โปรแกรมประยุกต์ของคุณมีหลายชนิดเอกสารหรือมุมมอง?

   แม้ว่าโปรแกรมประยุกต์ของคุณไม่ยืมเพื่อล้างเอกสาร/มุมมองแยกตัวเอง คุณจะยังคงสามารถโยกย้ายไป MFC 2.0 อย่างเต็มรูปแบบ และใช้ประโยชน์และจำเป็นอย่างยิ่งที่สมบูรณ์ของกรอบ คุณสามารถ "ปลอม" แยกมองเอกสาร โดยการใช้CDocument- CView-มาเรียน แต่เอกสารหรือมุมมองคลาอาจมอบงานของคลาอื่น ๆ ส่วนใหญ่ของคุณได้ หรือ คลาสมุมมองของคุณอาจต้องใช้CFrameWnd- หรือCMDIChildWndของคุณ-มาชั้นนำจำนวนมากส่วนติดต่อผู้ใช้ของโปรแกรมประยุกต์ของคุณไปใช้ ในสรุป คุณมีเสรีภาพเกือบทั้งหมดเป็นการวิธีการแยกเอกสารของคุณ มุมมอง และกรอบหน้าต่างชั้น?

   การวิเคราะห์ยังควรพิจารณาว่า โปรแกรมประยุกต์ของคุณจำเป็นต้องหลายมุมมองชั้นและอาจหลายเอกสารชั้น โปรแกรมประยุกต์ที่ง่ายแม้แต่ค่อนข้างบางครั้งจำเป็นมากกว่าหนึ่งมุมมองคลา อย่างไรก็ตาม มุมมองต่าง ๆ เช่นในหน้าต่างแยก ไม่จำเป็นต้องบอกว่า คุณมีหลายCView-มาเรียน ตัวอย่างเช่น ถ้าแต่ละบานในหน้าต่างแยกมีอินเทอร์เฟซผู้ใช้ที่เหมือนกันเป็นบานหน้าต่างอื่นในหน้าต่างแยก แล้วจะสามารถใช้ร่วมชั้นมุมมองเดียวกัน ในกรณีนี้ แต่ละบานมีเพียงแค่วัตถุแตกต่างกันของชั้นมุมมองเดียวกัน คุณอาจจะต้องการการออกแบบหลายมุมมองคลาสของ ถ้าโปรแกรมประยุกต์ของคุณมีอินเทอร์เฟซผู้ใช้ที่แตกต่างกันมากใน windows ที่แตกต่างกัน?

2. วิเคราะห์คุณลักษณะใดกรอบ AppWizard ที่ได้รับการสนับสนุนที่โปรแกรมประยุกต์ของคุณจะต้อง?

   AppWizard จะสร้างโครงกระดูกประยุกต์ MFC 2.0 ที่สนับสนุนคุณลักษณะกรอบต่าง ๆ ที่คุณเลือกเป็นตัวเลือกในกล่องโต้ตอบ AppWizard ก่อนที่คุณเรียกใช้ AppWizard ในการสร้างโปรแกรมประยุกต์ของโครงกระดูก คุณควรก่อนคุ้นเคยกับตัวเลือกแสดง AppWizard?

   แล้ว ใช้เวลาเล็กน้อยในการตัดสินใจที่ AppWizard ของตัวเลือกที่คุณต้องการเลือก อย่าพยายามที่จะทำได้ในไม่กี่นาทีเป็นครั้งแรกที่คุณเรียกใช้ AppWizard ตัวอย่างเช่น ถ้าโปรแกรมประยุกต์ของคุณไม่ได้สนับสนุน OLE อยู่การตัดสินใจหลักที่คุณจะต้องพิจารณา ถ้าคุณไม่ได้เลือกตัวเลือก OLE AppWizard ของการเริ่มต้นด้วย คุณจะยังคงสามารถปรับเปลี่ยนรหัสโปรแกรมประยุกต์ของคุณใช้คุณลักษณะ OLE ของ MFC แต่ที่เริ่มต้น ด้วยตัวเลือก OLE AppWizard เพื่อเริ่มต้น ด้วยจะประหยัดเวลาของคุณ?

   การวิเคราะห์ของคุณควรตรวจสอบว่าโปรแกรมประยุกต์ของคุณส่วนติดต่อแบบเอกสารเดี่ยว (SDI) หรือแอพลิเคชันอินเทอร์เฟซ (MDI) เอกสารหลาย กำหนดเฉพาะนี้ควรปรากฏชัดถ้าคุณคุ้นเคยกับอินเตอร์เฟซผู้ใช้ที่แตกต่างกันสองเหล่านี้ในโปรแกรมประยุกต์อื่น ๆ ของ Windows AppWizard จะสร้างโปรแกรมประยุกต์ MDI ตามค่าเริ่มต้นเนื่องจากอินเทอร์เฟซสำหรับผู้ใช้ MDI ถูกใช้งานมักจะได้มากกว่าเพื่อผู้ใช้สำหรับที่จะช่วยให้พวกเขาเปิดมากกว่าหนึ่ง/แฟ้มเอกสารครั้งนี้ โชคดี มีสถาปัตยกรรม/มุมมองเอกสาร MFC 2.0, MDI สนับสนุนต้องไม่เขียนโค้ดเพิ่มเติมในส่วนของคุณ?

3. สร้างโปรแกรมประยุกต์ใหม่โดยใช้ AppWizard?

   มีทำการวิเคราะห์ด้านบน คุณขณะนี้พร้อมที่จะเรียกใช้ AppWizard ในการสร้างรหัสโครงกระดูกสำหรับโปรแกรมประยุกต์ของคุณ?

   มีวิเคราะห์วิธีแยกโปรแกรมประยุกต์ของคุณลงในเอกสาร มุมมอง และกรอบ windows คุณควรมีความคิดที่ดีอะไรชื่อเพื่อให้ผู้เรียนที่สอดคล้องกันและโมดู คุณอาจต้องการกำหนดชื่อทั่วไปค่อนข้าง เช่นตัวบทสอนอย่างของ CScribDoc และ CScribView และ scribdoc.cpp และ scribvw.cpp อย่างไรก็ตาม ถ้าโปรแกรมประยุกต์ของคุณต้องใช้หลายมุมมองคลาสของ คุณคงต้องการให้มุมมองที่สร้าง AppWizard ชั้นแรกชื่อเพิ่มเติมพิเศษ เช่น CDataEntryView และ CReportView ดูขั้นตอนถัดไปสำหรับข้อมูลเพิ่มเติมเกี่ยวกับการสร้างคลาสที่เอกสารและมุมมองหลาย?

   มีตัวเลือก AppWizard ใดเพิ่มเติมที่คาดการณ์ไว้คุณ ต้อง เช่น SDI หรือ MDI และ OLE คุณควรจะสามารถเลือกตัวเลือกที่ AppWizard และสร้างแอพลิเคชันโครงกระดูกในเพียงไม่กี่นาที?

4. โคลนหรือ มุมมองที่สอง เอกสาร และกรอบหน้าต่างชั้น?

   หากการวิเคราะห์ด้านบนเป็นตัวกำหนดว่า โปรแกรมประยุกต์ของคุณควรมีหลายมุมมอง เอกสาร หรือกรอบหน้าต่างชั้น นั้นเป็นเวลาเหมาะสมเมื่อต้องการสร้างรหัสโครงกระดูกเหล่านี้เรียนขวาหลังจากที่คุณเรียกใช้ AppWizard?

   คุณสามารถสร้างรหัสโครงกระดูกของมุมมองเพิ่มเติม เอกสาร และกรอบหน้าต่างชั้น โดยรองรับการโคลนที่สร้าง โดย AppWizard กล่าวคือ คัดลอก.cpp และ.h แฟ้ม กำหนดชื่อโมดูลใหม่สำหรับเอกสารหรือชั้นสอง แล้ว แก้ไขรหัสโครงกระดูก โดยเปลี่ยนชื่อคลาส อีกหนึ่งทางเลือกการ ใช้ฟังก์ชันการทำงานเพิ่มคลาส ClassWizard ในการสร้างคลาใหม่โดยอัตโนมัติในแฟ้มคุณระบุโดยใช้ชื่อคุณระบุได้ คุณจะคุ้นเคยกับ ClassWizard สามารถสร้างคลาสที่ใหม่ถ้าคุณทำตามบทช่วยสอนการเขียน?

   ในกรณีใด ในCWinAppของคุณ-มาของคลาสInitInstanceฟังก์ชัน คุณต้องลงทะเบียนวัตถุแม่แบบเอกสารเพิ่มเติมสำหรับความสัมพันธ์ใด ๆ ที่คุณต้องการทำให้ระหว่างคุณหลายเอกสาร มุมมอง และกรอบหน้าต่างชั้น?

   ยังเป็นขั้นตอนอย่างรวดเร็ว คุณสามารถเลื่อนขั้นตอนนี้ถ้าคุณไม่ยอมรับการใช้งานหลายเอกสาร มุมมอง หรือกรอบหน้าต่างชั้นในโปรแกรมประยุกต์ของคุณ?

5. โยกย้ายของรหัส MFC 1.0 ในส่วนที่เกี่ยวข้องลงในคลาสที่สร้าง โดย AppWizard?

   ขั้นตอนนี้แทนเป็นกลุ่มของงานในการโยกย้ายโปรแกรมประยุกต์ของคุณ MFC 1.0 MFC 2.0 คุณควรทำแบบเพิ่มหน่วย โยกย้ายอย่างชัดเจนขนาดค่อนข้างเล็กของโปรแกรมประยุกต์ของคุณในเวลาเดียวกัน เมื่อคุณทำเช่นนี้ คุณจะได้ศึกษารายละเอียดเพิ่มเติมเกี่ยวกับฟังก์ชันใดมีกรอบที่จะอนุญาตให้คุณทิ้งบางส่วนของรหัสโปรแกรมประยุกต์ MFC 1.0 เก่า?

   ในขณะที่คุณย้ายอย่างชัดเจนเหล่านี้ของรหัส ระลึกแนวทางการนำเสนอภายใต้ "โยกย้ายที่น้อยที่สุด" หลายแนวทางดังกล่าวนำไปใช้กับการโยกย้ายแบบเต็ม AppWizard จะได้เรียบร้อยแล้วเพิ่มข้อคิดเห็น //{{AFX_MSG และ //{{AFX_MSG_MAP คลาสของเป้าหมายคำสั่งของคุณ (โปรแกรมประยุกต์ เอกสาร มุมมอง และกรอบหน้าต่าง) คุณไม่จำเป็นสำหรับคุณเพิ่มด้วยตนเองเหล่านี้เป็นภายใต้วิธีการโยกย้ายที่น้อยที่สุด แม้ว่าจะไม่จำเป็นต้องใช้ เราขอแนะนำให้ คุณย้ายฟังก์ชันการจัดการข้อความระหว่าง //{{AFX_MSG ข้อคิดเห็นในการแมปข้อความให้ซ้อนกันอยู่ ย้ายการประกาศค่าของฟังก์ชัน (afx_msg) การจัดการข้อความเหล่านี้ระหว่าง //{{AFX_MSG ข้อคิดเห็นในหัวข้อแฟ้มต่าง ๆ ของคุณ การทำเช่นนี้จะอนุญาตให้คุณใช้ ClassWizard ตลอดส่วนเหลือของโครงการของคุณ life cycle(s)?

   คำแนะนำเหล่านี้เกี่ยวกับความคิดเห็น //{{AFX_MSG ยังใช้ บางทีกับปริญญาน้อยกว่า การใช้กล่องโต้ตอบนั้น ถ้าคุณไม่คาดว่าจะเปลี่ยนแปลงอย่างมากในอนาคตการโต้ตอบที่กำหนดชั้น แล้วซึ่งอาจไม่คุ้มค่าของความพยายามในการทำการโต้ตอบที่ทราบ ClassWizard ที่จะดี เราขอแนะนำ หลักสูตร ที่ คุณสร้างระดับทั้งหมดใหม่โต้ชั้นโดยใช้ตัวเลือกเพิ่มคลา ClassWizard ของ?

   ในขณะที่คุณย้ายโปรแกรมประยุกต์ MFC 1.0 หรือ Windows คุณอาจต้องการที่รักษาความเข้ากันได้กับรูปแบบแฟ้มที่มีอยู่ (กลไก MFC 2.0 อนุกรมเอกสารเริ่มต้นอาจจะไม่เหมาะสมสำหรับโปรแกรมประยุกต์ของคุณ) โดยตรงCFileเขียน และอ่านสาย หรือการใช้ไม่ใช่แฟ้มเอกสารที่ใช้ คุณจะต้องการแทนที่CDocument::OnOpenDocumentและOnSaveDocument ตัวอย่างทั่วไปของ MFC DIBLOOKแสดงตัวอย่างของเทคนิคนี้ ถ้าโปรแกรมประยุกต์ของคุณปัจจุบันอยู่แล้วจะไม่เป็นปัญหาวัตถุ serializes?

การเปลี่ยนแปลงตัวอักษร API

การทำความเข้าใจเหตุผลสำหรับการเปลี่ยนแปลงเหล่านี้ โปรดดู "เหตุผลสำหรับการเปลี่ยนแปลง" ด้านล่าง?

เหตุผลสำหรับการเปลี่ยนแปลง:

• ฟังก์ชันการทำงานดีขึ้น รุ่น MFC 2.0 ของ API นี้ให้ปรับปรุง หรือเพิ่มเติมผ่านของปฏิมากร MFC 1.0?
  
  
• เคร่งครัดอัจฉริยะ API 2.0 MFC ถูกเปลี่ยนแปลงเพื่อให้สอดคล้องกับ Windows API แบบเคร่งครัด?
  
  
• ความถูกต้อง const API 2.0 MFC ที่กำหนดเพื่อใช้คำสำคัญ 'const' เพื่ออำนวยความสะดวกที่มีเสถียรภาพมากขึ้นโปรแกรมอย่างถูกต้อง?
  
  
• Win32 portability API 2.0 MFC มีการเปลี่ยนแปลงการแสดงอย่างถูกต้องใน Win32 API ซึ่งสะดวก++:การสร้างพอร์ตง่าย ๆ ของโปรแกรมประยุกต์ Win32 MFC?
  
  
• การใช้หน่วยความจำลดลง API 2.0 MFC ถูกเปลี่ยนแปลงเพื่อให้มีประสิทธิภาพยิ่งในการเชื่อมและเทคนิคการใช้งานหน่วยความจำซึ่งจะส่งผลให้ในโปรแกรมประยุกต์ที่มีขนาดเล็กลงและลดการใช้DGROUP?
  
  
• 3.1 ชนะฟังก์ชัน API 2.0 MFC ถูกเปลี่ยนแปลงเพื่อแสดงการเปลี่ยนแปลง Windows 3.1 API อย่างถูกต้อง API ยังคงเข้ากันได้กับ Windows 3.0 แต่เดี๋ยวนี้มีพารามิเตอร์เฉพาะ Windows 3.1 ก็ได้?

ข้อผิดพลาดของคอมไพเลอร์

การเปลี่ยนแปลง APIs 2.0 MFC ส่วนใหญ่จะสร้างหนึ่งในไม่กี่ข้อผิดพลาดของคอมไพเลอร์ หรือไม่มีเลยถ้าแปลงชนิดมาตรฐานตอบสนองคอมไพเลอร์ ข้อผิดพลาดของคอมไพเลอร์ดังต่อไปนี้อาจถูกสร้างขึ้นเมื่อการคอมไพล์โปรแกรมประยุกต์ MFC 1.0 อยู่ภายใต้ MFC 2.0:

หมายเหตุด้านเทคนิคตามหมายเลข|nbsp หมายเหตุด้านเทคนิคตามประเภท(&N)