Virtual Developer Workshop: Containerized Development with Docker

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(
    RUNTIME_CLASS(CChildFrame), // custom MDI child frame

  // 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.


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.


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, 
                             (void**)&pIDoc) );

And to use it:

BOOL CExeApp::InitInstance()
  // Register the application's document templates.
  // Document templates serve as the connection between
  // documents, frame windows and views.
  CMultiDocTemplate* pDocTemplate;
  pDocTemplate = new CMultiDocTemplate(
    RUNTIME_CLASS(CChildFrame), // custom MDI child frame
  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;

To release interface:

int CExeApp::ExitInstance() 
  // TODO: Add your specialized code here and/or call 
  // the base class

  return CWinApp::ExitInstance();

void CExeApp::ReleaseDll()


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.


Download demo project - 66 Kb


  • Can you give me some advice?

    Posted by Legacy on 11/01/2003 08:00am

    Originally posted by: XiaoGan Wang

    I am a student in an Universtity.In my thesis,I have to display a curve to record real_time data. Your "dll.dll" is very useful. Thank you!

    The structure of my soft is:

    1. DataSupply.DLL:This dll supply real_time data and an export funcion for "dll.dll"; "dll.dll" create a window to display curve.

    2. DisplaySet.DLL:This dll does some setting work.It must communicate with "dll.dll" , DataSupply.DLL and my exe(its name is Real_time Data Record).It creates a dialog and show the dialog when soft is being initialized. It has a lot of buttons and Edit boxs.

    3. Your "dll.dll" should do:Create a popup window when my soft is being initialized.I want to transfer an export function of "dll.dll" to create and show a window,but I can not use a CWinApp Object to do it in CExeApp::InitInstance() because my App's InitInstance() will to create my control panel window.

    4. EXE is same as control panel.It is a SDI window.

    My question is how to use dll.dll to create and show a window when my soft is being initialized.The pop_up window created by "dll.dll" is the result of transferring the export function of "dll.dll" by EXE when soft is being initialized. At the same time,My EXE's SDI window is not
    Created by "dll.dll". If I use your "dll.dll",how to do?

    pThis->m_pWinApp = pWinApp; (dll.dll)

    pIDoc->CreateDocTempl(this, C_DOC_1); (exe.exe)

    I think I should rework them,but I do not know how to do ......

    Can you give me some advice or source code if you have?

    Thank you!
    My E_Mail:softdevelop@tom.com

  • Store the View/Doc architecture in dll

    Posted by Legacy on 07/01/2003 07:00am

    Originally posted by: Giorgos

    Excellent, thank you!

  • How to implement this kind of mechanism on WTL?

    Posted by Legacy on 06/10/2003 07:00am

    Originally posted by: bleleer

    Good job!
    Anyway, can implement this mechanism with WTL(both of exe and dll on WTL)?


  • How to implement SDI ?

    Posted by Legacy on 05/04/2003 07:00am

    Originally 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 !

  • Hmmm... How to seperate MainFrame into the Exe

    Posted by Legacy on 03/20/2003 08:00am

    Originally 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....
    - Has the main window
    - creates a mdi client
    - loads the 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

  • So good, just what I looking for

    Posted by Legacy on 10/24/2002 07:00am

    Originally posted by: James Yu

    Excellent article, run a MFC application from a dll, just what I need.
    One 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.

  • Isn't it already in MFC dll?

    Posted by Legacy on 04/30/2002 07:00am

    Originally posted by: Chetan Joshi


    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
    out 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 07:00am

    Originally 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

    Any solutions to this caveat?


  • You must have javascript enabled in order to post comments.

Leave a Comment
  • Your email address will not be published. All fields are required.

Most Popular Programming Stories

More for Developers

RSS Feeds

Thanks for your registration, follow us on our social networks to keep up-to-date