Share the View/Doc Architecture in a DLL
This article was contributed by Alexandre Komyak.
Tested on: VC++ 4/6 NT2000
My current project made me think on the following point:
It would be useful to separate into a dll the code responsible for running MFC's View/Doc architecture, notably frame, its child area with controls, dialogs etc. This would help different applications to share a grand part of the code.
This article describes a proposed solution. Both SDI and MDI interfaces have been tested. MDI-based applications are the concerned here.
CExeApp is derived from CWinApp. CExeApp::InitInstance contains the code to create document templates and main frame.
CMultiDocTemplate* pDocTemplate;
pDocTemplate = new CMultiDocTemplate(
IDR_EXETYPE,
RUNTIME_CLASS(CExeDoc),
RUNTIME_CLASS(CChildFrame), // custom MDI child frame
RUNTIME_CLASS(CExeView));
AddDocTemplate(pDocTemplate);
// create main MDI Frame window
CMainFrame* pMainFrame = new CMainFrame;
if (!pMainFrame->LoadFrame(IDR_MAINFRAME))
return FALSE;
m_pMainWnd = pMainFrame;
What if we move the above code into a dll? This would be done along with the code other classes (CExeDoc, CChildFrame, CExeView), and resources (IDR_MAINFRAME).Having done this, we'll separate all the Frame/Doc/View stuff into the library that may be reusable by CWinApp based applications.
The attached file comprises two sub-folders, exe and dll. dll is an implementation of the View/Doc architecture in Dll. exe is executable that is linked with dll.
dll:
It must be an MFC extension Dll and provide ann interface class to be used by the exe application:
// interface class identifier #define CLSID_APP 0x10 // interface IDs #define IID_MyIUnknown 0x1000 #define IID_IDocument 0x1001 // document constants #define C_DOC_1 0x100 #define C_DOC_2 0x101 // instantiate an interface class object BOOL __declspec(dllexport) App_GetClassObject(int nClsid, int nId, void** ppvObj); // defined instead of MFC's IUnknown struct MyIUnknown { MyIUnknown() { TRACE("Entering IUnknown ctor %p\n", this); } virtual BOOL QueryInterface(int nIid, void** ppvObj) = 0; virtual DWORD Release() = 0; virtual DWORD AddRef() = 0; }; struct AFX_EXT_CLASS IDocument : public MyIUnknown { IDocument() { TRACE("Entering IDocument ctor %p\n", this); } virtual CDocTemplate* CreateDocTempl( CWinApp*, int ) = 0; virtual void CreateFrame() = 0; };
Thus, IDocument is an interface class. App_GetClassObject() is used to create an object to be controled via its interface. In the code supplied, IDocument is defined in dll_inteface.h. Implementation is hidden in App.[h,cpp] files.
How to create dll. First, we have to create the CWinApp exe application with AppWizzard. Then create dll MFC extension project (again AppWizzard). All of the exe's Frame/Doc/View files move to dll. Create class a wizard database for dll. It must include all the classes for frames, views and documents. Move all the necessary resources from exe to dll. Finally, Build.
exe:
After moving the files, there is exe.[h,cpp] and stdafx.[h,cpp]. We have to add the lines to initialize IDocument interface:
void CExeApp::InitDll()
{
VERIFY( App_GetClassObject(CLSID_APP,
IID_IDocument,
(void**)&pIDoc) );
}
And to use it:
BOOL CExeApp::InitInstance()
{
InitDll();
...
// Register the application's document templates.
// Document templates serve as the connection between
// documents, frame windows and views.
/*
CMultiDocTemplate* pDocTemplate;
pDocTemplate = new CMultiDocTemplate(
IDR_EXETYPE,
RUNTIME_CLASS(CExeDoc),
RUNTIME_CLASS(CChildFrame), // custom MDI child frame
RUNTIME_CLASS(CExeView));
AddDocTemplate(pDocTemplate);
*/
pIDoc->CreateDocTempl(this, C_DOC_1);
// create main MDI Frame window
/* CMainFrame* pMainFrame = new CMainFrame;
if (!pMainFrame->LoadFrame(IDR_MAINFRAME))
return FALSE;
m_pMainWnd = pMainFrame;
*/
pIDoc->CreateFrame();
...
}
To release interface:
int CExeApp::ExitInstance()
{
// TODO: Add your specialized code here and/or call
// the base class
ReleaseDll();
return CWinApp::ExitInstance();
}
void CExeApp::ReleaseDll()
{
pIDoc->Release();
}
conclusion:
The presented inteface class is the minimum needed. It should be advanced for your particular case. Applications may change frame, menu, icon, some aspects of its view, etc. using the same Dll.

Comments
Nike Air Max+instagram, at one's desire you confine the color to wear on your feet!
Posted by madytreathy on 04/24/2013 05:06pmRecognize in 2008, if not earlier, when Nike launched up ahead of the independent shoe color projects, the catchword "Whiz Your Colours", "Nike PhotoiD" arrangement, [url=http://fossilsdirect.co.uk/glossarey.cfm]nike huarache free[/url] response has not been as enthusiastic as expected. About, 2008 Canon IXUS 80 IS Digital file card arcade but contrariwise 8 million pixels, Nokia, the mobile phone retail is the one regulation, NikeiD was promote to color in the photos as a infrastructure someone is concerned sneakers levy color, although interesting, but does provoke some. Instagram which cause this passion fun and simple, Nike PHOTOiD homeopathic upgrade customization services, recently [url=http://markwarren.org.uk/goodbuy.cfm]nike free[/url] released a new plan. That such iD can you appliance pictures as instagram account shoe color, for a short offer Nike Mood Max shoes and Nike Refresh Max 1, Nike Air Max 90 953 options. Interested in children's shoes, you [url=http://fossilsdirect.co.uk/glossarey.cfm]nike huarache[/url] can always associate with's valid website photoid.Nike.com, in reckoning to skim through other people's ingenious industry, or you can make an effort to upload your own instagram photo, base your own Nike Hauteur Max.
ReplyCan you give me some advice?
Posted by Legacy on 11/01/2003 12:00amOriginally posted by: XiaoGan Wang
ReplyStore the View/Doc architecture in dll
Posted by Legacy on 07/01/2003 12:00amOriginally posted by: Giorgos
Excellent, thank you!
ReplyHow to implement this kind of mechanism on WTL?
Posted by Legacy on 06/10/2003 12:00amOriginally posted by: bleleer
Good job!
Anyway, can implement this mechanism with WTL(both of exe and dll on WTL)?
Thanks.
ReplyHow to implement SDI ?
Posted by Legacy on 05/04/2003 12:00amOriginally posted by: Smash
Hi !
Can you give an example of SDI instead of MDI ? I have done all the obvious changes, but I always have an error - "Can't create an empty document".
Are there any specific changes needed ?
Thank you !
ReplyHmmm... How to seperate MainFrame into the Exe
Posted by Legacy on 03/20/2003 12:00amOriginally posted by: monu
This is not bad... but for a project that I am currently working on, I need to seperate the main frame (CMDIFrame) into the EXE and then various doc/views into the DLL....
I think this is a more useful thing to do .... and am having lots of problems
So this is what I am working on....
EXE
- Has the main window
- creates a mdi client
- loads the dll
DLL
- creates the mdichild (by asking the main frame in exe)
- loads the view/doc etc.
On top of this the EXE is in Win32 and DLL is in MFC.... I can creates everything alright, however at times (intermittently) things crash deep inside the MFC
any help is much appreciated
ReplySo good, just what I looking for
Posted by Legacy on 10/24/2002 12:00amOriginally posted by: James Yu
Excellent article, run a MFC application from a dll, just what I need.
ReplyOne point, I may write a normal dll as a mediator for my usage, because this is an extanded dll. For my executable exe is not a MFC appliction. Extanded dll can only be linked by MFC applications.
http://www.codeguru.com/mfc/comments/5164.shtml
thanks
James
Isn't it already in MFC dll?
Posted by Legacy on 04/30/2002 12:00amOriginally posted by: Chetan Joshi
Hello
Microsoft created MFC????.Dll(s) for precisely the
same reason. This idea was relevant with MFC ver 1
and 2. MFC was implemented at that time as a static
library and you needed to create extensions.
Instead of discouraging you, I would like to point
Replyout above point and suggest that you think of idea
that will significantly improve or extend Doc/View
architecture and then create DLL for that.
problem with resource
Posted by Legacy on 04/28/2002 12:00amOriginally posted by: okigan
I have investigated that topic before.
To my disappointment the problem always comes
when resources are infolved, actually 2 problems:
*The resource id either has to match between
main app and the dlls, or
*The resources must NOT overlap
The two problems kinda kill the idea of plugin
document/views...
Any solutions to this caveat?
Regards
Reply