Diff between CreateNewFrame() and LoadFrame() for new views?

Posted on 1998-07-10
Last Modified: 2013-11-19
I have a document that contains data gathered from remote testers. It's not a file that the user can open. I have a view showing the data in text format in a grid. I want another view summarizing the data in a bar chart. Currently I am opening the new view's window by creating a doc template in InitInstance() like so:

               // this done by class wizard:
      CMultiDocTemplate* pDocTemplate;
      pDocTemplate = new CMultiDocTemplate(
            RUNTIME_CLASS(CChildFrame),      // this frame has 'X' disabled, and other customizations

               // my new template
      m_pSummaryViewTemplate = new CMultiDocTemplate(
            IDR_OVEN_SUMMARY,               // refers only to a string resource, not a menu or icon

Then I open the frame from a menu handler with CDocTemplate::CreateNewFrame per the CHKBOOK sample or Blaszczak pg 196. This is working with some caveats, see below.

I understand I could also creat a new view/frame using LoadFrame() and a CCreateContext object. What's the difference?  Which is the better route? A timer running in the main view should do an UpdateAllViews() when it trips.

The caveats mentioned above are 1) My summary frame title is the same as my CHostView frame, not the one I thought would be referenced by my IDR_OVEN_SUMMARY string, and 2) I want both child windows to have the same menu options, and MFC is greying out the ones it thinks my summary shouldn't have. The VIEWEX sample seemed to do what I was doing, but its menus are the same for both views. I do NOT want to maintain 2 menus like they did in CHKBOOK.

Thanks for your help on this,
Question by:nchenkin
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 5
  • 3
  • 2

Expert Comment

ID: 1319002
-- You are probably storing the template m_pSummaryViewTemplate in Iyour CWinApp, so wherever you want to open the view, do a OpenDocumentFile to get your document object.

CMyWinApp* pApp = (CMyWinApp*) AfxGetApp( );
CDocument* pDoc = pApp->m_pSummaryViewTemplate->OpenDocumentFile( NULL );      

-- This way your frame title is changed with

pDoc->SetTitle( "Your Title" );

-- To get your menu options, the way I do it is to either have two menus, one for IDR_OVEN_SUMMARY and one for IDR_HOSTTYPE.  Therefore, the menus will be highlighted, enabled, or checked per your current class.


Expert Comment

ID: 1319003
Oops, missed the comment about not wanting two menus.  OK, shot in the dark... how about a dummy menu for IDR_OVEN_SUMMARY and once it is created, do a SetMenu function on the view?

Author Comment

ID: 1319004
Hello psdavis,

Your OpenDocumentFile(NULL) is *yet another approach* and it seems to be working although I'd like to understand how calling it with NULL opened the correct document. But maybe I should just have faith and leave it at that! My window title now also is correct per my IDR_OVEN_SUMMARY resource string, so we've made progress.

But creating a dummy menu doesn't happen. If I just do an "Insert Menu" in my resource list, teh compiler deletes this if I haven't actually edited anything in the menu.

Next step?
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!


Author Comment

ID: 1319005
Actually, after playing with OpenDocumentFile(), I decided that I don't want to open another document, I just want a new view of an already open document.

This brings me back, I think,  to my original question of CreateNewFrame() vs LoadFrame() / CCreateContext.


Expert Comment

ID: 1319006
The OpenDocumentFile does perform the CreateNewFrame.  It's more of a wrapper than anything.  The NULL is for passing a file name to open.  The CMultiDocTemplate stores the name of the CDocument so it knows the document when it does the OnNewDocument.

I'll take a separate look at having two documents with only one menu in a bit.

Expert Comment

ID: 1319007
The OpenDocumentFile does perform the CreateNewFrame.  It's more of a wrapper than anything.  The NULL is for passing a file name to open.  The CMultiDocTemplate stores the name of the CDocument so it knows the document when it does the OnNewDocument.

I'll take a separate look at having two documents with only one menu in a bit.

Expert Comment

ID: 1319008
Not that I'm trying to avoid your question, but if you have an existing document, and you want to add a new view to that document, then the CDocument::AddView( CView* ) function is probably more your style.

Accepted Solution

piano_boxer earned 100 total points
ID: 1319009
Here is a function that will open a new view attached to the current document.
USAGE: OpenNewView(pExistingDoc, RUNTIME_CLASS(CMySuperView), "My Syper View");

void OpenNewView(CDocument* pDoc, CRuntimeClass* pClass, LPCSTR lpszTitle)

    // Create the frame
    CMDIChildWnd* pFrame = new CMDIChildWnd;
    pf->m_strViewTypeName = lpszTitle;
    pf->m_strDocTitle = pDoc->GetTitle();

    CCreateContext cc;
    cc.m_pNewViewClass = pClass;
    cc.m_pCurrentDoc = pDoc;
    cc.m_pNewDocTemplate = NULL;
    cc.m_pLastView = NULL;
    cc.m_pCurrentFrame = NULL;

    // Create frame and view    
    pFrame->Create(NULL,pDoc->GetTitle(), WS_CHILD | WS_OVERLAPPEDWINDOW, CMDIChildWnd::rectDefault, NULL, &cc);

Author Comment

ID: 1319010
Hello piano_boxer,

I think that's what I was looking for!

There were compile errors on ASSERT_VALID(pClass) and the undeclared pf and its members, but once I nuked them it was OK.

CDoc::UpdateAllViews() is working so the new frames are attached to the right doc. I still need to figure out how to keep my menu items enabled when this frame has focus, but I should be able to handle that.


Expert Comment

ID: 1319011
Ok, sorry for my mistakes.

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
Get filename and folder into excel 7 84
abstract class with all non abstract mentods 6 84
wordappend challenge 8 225
Change to event 1 129
Introduction: Dialogs (1) modal - maintaining the database. Continuing from the ninth article about sudoku.   You might have heard of modal and modeless dialogs.  Here with this Sudoku application will we use one of each type: a modal dialog …
Exception Handling is in the core of any application that is able to dignify its name. In this article, I'll guide you through the process of writing a DRY (Don't Repeat Yourself) Exception Handling mechanism, using Aspect Oriented Programming.
This video will show you how to get GIT to work in Eclipse.   It will walk you through how to install the EGit plugin in eclipse and how to checkout an existing repository.
The Email Laundry PDF encryption service allows companies to send confidential encrypted  emails to anybody. The PDF document can also contain attachments that are embedded in the encrypted PDF. The password is randomly generated by The Email Laundr…

696 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question