[ Pobierz całość w formacie PDF ]
.DEF, musisz podaæ stworzone przez kompilator udekorowane nazwy klas i funkcji.Na szczêœcie MFC posiada kilka makr, które to znacznie u³atwiaj¹.Eksportuj¹c z biblioteki ca³¹ klasê, w deklaracji klasy mo¿esz zastosowaæ makro AFX_EXT_CLASS:class AFX EXT_CLASS CMyFancyToolbar : public CToolbar.Eksportowanie czêœci klasy jest równie ³atwe.Zamiast umieszczaæ makro AFX_EXT_CLASS przed nazw¹ klasy, umieœæ je bezpoœrednio przed nazw¹ funkcji, któr¹ chcesz wyeksportowaæ:class CMyFancyDialog : public CDialog{public:AFX_EXT_CLASS CMyFanceDialog() ; AFX_EXT_CLASS int DoModal(); public:BOOL Create(LPCTSTR 1pszTemplateName, CWnd* pParentWnd = NULL); BOOL Create(UINT nIDTemplate, CWnd* pParent = NULL);.Zwróæ uwagê, ¿e w klasie CMyFancyDialog jest eksportowany konstruktor klasy oraz funkcja DoModal (), lecz nie s¹ eksportowane dwie przeci¹¿one wersje funkcji Create ().Oznacza to, ¿e klient mo¿e konstruowaæ klasê i wywo³ywaæ jej funkcjê DoModal (), lecz jeœli bêdzie posiada³ w swoim kodzie wywo³anie którejœ z przeci¹¿onych funkcji Create (), budowa programu nie powiedzie siê, gdy¿ program ³¹cz¹cy nie bêdzie móg³ znaleŸæ odpowiednich funkcji.Makro AFX_EXT_CLASSJak ju¿ wiemy, makro AFX_EXT_CLASS mo¿e zostaæ u¿yte do eksportowania albo ca³ych klas, albo ich czêœci.Jednak, gdy aplikacja klienta do³¹cza do siebie plik nag³Ã³wkowy zawieraj¹cy deklaracje klas eksportowanych przez DLL-a, pojawia siê problem, gdy¿ oba modu³y informuj¹ program ³¹cz¹cy, ¿e s¹ odpowiedzialne za eksportowanie klasy.Ten potencjalny problem jest rozwi¹zywany dziêki sposobowi zdefiniowania makra AFX_EXT_CLASS, które zale¿y od poni¿szych definicji preprocesora w projekcie:Jeœli w projekcie s¹ zdefiniowane symbole _AFXDLL oraz _AFXEXT, makro AFX_EXT_ c LAS s jest rozwijane nastêpuj¹co:_declspec(dllexport)Jeœli _AFXEXT nie jest zdefiniowane, makro AFX_EXT_CLASS jest rozwijane nastêpuj¹co w celu importowania klasy:_declspec(dllimport)Tak wiêc, gdy AppWizard tworzy bibliotekê rozszerzeñ MFC, definiuje zarówno symbol _AFXDLL jak i _AFXEXT.Za ka¿dym razem, gdy kod Ÿród³owy DLL-a odwo³uje siê do makra AFX_EXT_CLASS, klasa jest eksportowana.U¿ycie zagnie¿d¿onych bibliotek rozszerzeñ MFCJak ju¿ wspominaliœmy, makro AFX_EXT_CLASS jest u¿ywane do eksportowania z biblioteki DLL ca³ych klas lub ich czêœci.Jeœli jednak aplikacja chce u¿yæ zagnie¿d¿onych bibliotek rozszerzeñ MFC, mo¿e pojawiæ siê problem.Za³Ã³¿my, ¿e masz bibliotekê rozszerzeñ MFC ze standardowymi procedurami i klasami, u¿ywanymi we wszystkich projektach.Nazwijmy t¹ bibliotekê bibliotek¹ „standardow¹".Mo¿esz tak¿e posiadaæ inn¹ bibliotekê rozszerzeñ MFC, zawieraj¹c¹ standardowe procedury i klasy dla okreœlonego projektu, któr¹ nazwiemy bibliotek¹ „projektu".Biblioteka DLL projektu prawie na pewno bêdzie korzystaæ ze standardowej biblioteki DLL.Oto „standardowy" przyk³ad zagnie¿d¿onych bibliotek rozszerzeñ DLL.Gdy spróbujesz ³¹czyæ bibliotekê projektu, mo¿esz otrzymaæ komunikaty b³êdów programu ³¹cz¹cego , gdy¿ zarówno biblioteka standardowa jak i biblioteka projektu u¿ywaj¹ tego samego makra i deklaruj¹ tê sam¹ klasê, choæ w rzeczywistoœci biblioteka projektu ma importowaæ tê klasê.Rozwi¹zanie tego problemu jest proste.Zamiast u¿ywaæ makra AFX_EXT_CLASS, powinieneœ u¿yæ makra bior¹cego po uwagê projekt, który je wykorzystuje.Na przyk³ad, mo¿esz stworzyæ standardowe makro o nazwie COMMON_IMPORT_EXPORT i zdefiniowaæ je jak w przyk³adzie poni¿ej.Plik nag³Ã³wkowy u¿ywany do deklarowania klas i funkcji eksportowanych przez standardow¹ bibliotekê u¿ywa makra COMMON_IMPORT_EXPORT zamiast makra AFX_EXT_CLASS.Zalet¹ jest to, ¿e tylko standardowa biblioteka bêdzie eksportowa³a swoje klasy.Wszystkie inne modu³y bêd¹ je importowaæ.Jednym ze sposobów zdefiniowania symbolu _COMMON_DLL dla standardowej biblioteki jest zdefiniowanie go w oknie dialogowym Project Settings dla tej biblioteki.#ifdef _COMMON_DLL#define COMMON_IMPORT_EXPORT_dêcisc(dllexport)#elsettdefine COMMON_IMPORT_EXPORdeclspec(dllexport)#endifEksportowanie zasobówKa¿da aplikacja MFC posiada po³¹czon¹ listê obiektów CDynLinkLibrary.Jeœli twój kod w aplikacji MFC wymaga, by MFC samo ³adowa³o zasoby, MFC najpierw próbuje za³adowaæ ¿¹dany zasób z bie¿¹cego modu³u.Do zlokalizowania zasobów modu³u MFC wykorzystuje funkcjê AfxGetResourceHandle ().Jeœli ¿¹dany zasób nie mo¿e byæ zlokalizowany, MFC „przechodzi" przez listê obiektów CDynLinkLibrary w celu zlokalizowania zasobu.Aby wskazaæ domyœlny modu³, od którego MFC rozpocznie wyszukiwanie, musisz u¿yæ funkcji AfxSetResourceHandle () w celu okreœlenia uchwytu HINSTANCE modu³u.Pisanie demonstracyjnej biblioteki DLL rozszerzeñ MFC zawieraj¹cej dokumenty i widokiPoniewa¿ ¿yjemy w czasach opartego na komponentach, wielokrotnie wykorzystywanego oprogramowania, ta demonstracyjna biblioteka rozszerzeñ MFC bêdzie ilustrowaæ sposób, w jaki mo¿emy zawrzeæ w bibliotece DLL obs³ugê modelu dokument-widok.Za³Ã³¿my, ¿e napisa³eœ dokument i widok, w celu obs³ugi odczytywania obrazków w plikach.JPG.Byæ mo¿e musisz napisaæ aplikacjê, która miêdzy innymi musi wyœwietlaæ te obrazki.Normalnie stworzy³byœ klasy dokumentu i widoku obs³uguj¹ce te pliki wewn¹trz swojej g³Ã³wnej aplikacji
[ Pobierz całość w formacie PDF ]