CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 43
  1. #16
    sunnysky Guest

    Re: Adding Splitter Windows Makes Mainframe Unable to Get Current Document

    That happens when I do things from scratch. I got NULL CDocument pointer when using GetActiveDocument(). This is shown in the attached program in the same projects.

    Quote Originally Posted by VictorN View Post
    What problems will you have?
    Attached Files Attached Files

  2. #17
    sunnysky Guest

    Re: Adding Splitter Windows Makes Mainframe Unable to Get Current Document

    Got it. I was just expecting some more standard learning approach.

    Quote Originally Posted by VictorN View Post
    But you will see all the needed methods/calls/initializations!
    Then compare with your own code... Perhaps you will want to add something tha your code does not have...

  3. #18
    sunnysky Guest

    Re: Adding Splitter Windows Makes Mainframe Unable to Get Current Document

    The generated "Windows Explorer" style code doesn't do SetActiveView() in CMainFrame::OnCreateClient() after creating the split views. Strange.

  4. #19
    VictorN's Avatar
    VictorN is offline Super Moderator Power Poster
    Join Date
    Jan 2003
    Location
    Hanover Germany
    Posts
    20,395

    Re: Adding Splitter Windows Makes Mainframe Unable to Get Current Document

    SetActiveView is called from CFrameWnd::InitialUpdateFrame method.
    Victor Nijegorodov

  5. #20
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: Adding Splitter Windows Makes Mainframe Unable to Get Current Document

    1) your mainframe shouldn't interact with the document. This is a fairly basic premise of MFC, if you are, then it's probably an indication you aren't properly embracing the document/view concept (note there is no mention of 'frame' in this name).
    Yes, there's exceptions...

    2) if you have multiple views, but are using the SDI approach anyway, then you will need to create your own document/view manager code.
    in it's most basic form, this means you override the GetActiveDocument() virtual to make it work with your view layout.

    what you could do is enumerate the views and query the active one
    or you could walk the splitter chain and derive the active view from there
    or you could have each view register itself in the frame, where you store view pointers in an array, then iterate the array
    or if you know there's only one document, have the view set a member of the frame that holds the document pointer, then return that from GetActiveDocument()
    ...

  6. #21
    sunnysky Guest

    Re: Adding Splitter Windows Makes Mainframe Unable to Get Current Document

    I found CFrameWnd::InitialUpdateFrame is called indirectly from "if (!ProcessShellCommand(cmdInfo))" statement in the CAlohaApp::InitInstance() function. But it wasn't called in an application built from "MFC Standard" style. How do we know under what circumstances it is called?

    Quote Originally Posted by VictorN View Post
    SetActiveView is called from CFrameWnd::InitialUpdateFrame method.

  7. #22
    sunnysky Guest

    Re: Adding Splitter Windows Makes Mainframe Unable to Get Current Document

    I am learning MFC while getting familiar with our existing project. Unfortunately our existing project is using this ad-hoc approach.

    Do you know any book teaching the approaches you mentioned?

    Thanks a lot.

    Quote Originally Posted by OReubens View Post
    1) your mainframe shouldn't interact with the document. This is a fairly basic premise of MFC, if you are, then it's probably an indication you aren't properly embracing the document/view concept (note there is no mention of 'frame' in this name).
    Yes, there's exceptions...

    2) if you have multiple views, but are using the SDI approach anyway, then you will need to create your own document/view manager code.
    in it's most basic form, this means you override the GetActiveDocument() virtual to make it work with your view layout.

    what you could do is enumerate the views and query the active one
    or you could walk the splitter chain and derive the active view from there
    or you could have each view register itself in the frame, where you store view pointers in an array, then iterate the array
    or if you know there's only one document, have the view set a member of the frame that holds the document pointer, then return that from GetActiveDocument()
    ...

  8. #23
    VictorN's Avatar
    VictorN is offline Super Moderator Power Poster
    Join Date
    Jan 2003
    Location
    Hanover Germany
    Posts
    20,395

    Re: Adding Splitter Windows Makes Mainframe Unable to Get Current Document

    Quote Originally Posted by sunnysky View Post
    I found CFrameWnd::InitialUpdateFrame is called indirectly from "if (!ProcessShellCommand(cmdInfo))" statement in the CAlohaApp::InitInstance() function. But it wasn't called in an application built from "MFC Standard" style. How do we know under what circumstances it is called?
    From MSDN:
    CFrameWnd::InitialUpdateFrame
    void InitialUpdateFrame( CDocument* pDoc, BOOL bMakeVisible );

    Parameters

    pDoc

    Points to the document to which the frame window is associated. Can be NULL.

    bMakeVisible

    If TRUE, indicates that the frame should become visible and active. If FALSE, no descendants are made visible.

    Remarks

    Call IntitialUpdateFrame after creating a new frame with Create. This causes all views in that frame window to receive their OnInitialUpdate calls.

    Also, if there was not previously an active view, the primary view of the frame window is made active. The primary view is a view with a child ID of AFX_IDW_PANE_FIRST. Finally, the frame window is made visible if bMakeVisible is nonzero. If bMakeVisible is 0, the current focus and visible state of the frame window will remain unchanged. It is not necessary to call this function when using the framework's implementation of File New and File Open.
    open the winfrm.cpp file, find CFrameWnd::InitialUpdateFrame method and set a break point on it.
    Then start debugger (F5). When debugger will break on this method - look at the Call stack window to see how and where from you came to this point...
    Victor Nijegorodov

  9. #24
    sunnysky Guest

    Re: Adding Splitter Windows Makes Mainframe Unable to Get Current Document

    "CWnd* pWnd = GetDescendantWindow(AFX_IDW_PANE_FIRST, TRUE);" in CFrameWnd::InitialUpdateFrame() returns NULL in the project built from "MFC Standard" style even though "bMakeVisible" is TRUE.

    Quote Originally Posted by VictorN View Post
    From MSDN:
    open the winfrm.cpp file, find CFrameWnd::InitialUpdateFrame method and set a break point on it.
    Then start debugger (F5). When debugger will break on this method - look at the Call stack window to see how and where from you came to this point...

  10. #25
    VictorN's Avatar
    VictorN is offline Super Moderator Power Poster
    Join Date
    Jan 2003
    Location
    Hanover Germany
    Posts
    20,395

    Re: Adding Splitter Windows Makes Mainframe Unable to Get Current Document

    In my test if I select "MFC Standard" instead of "Windows Explorer"
    the following code is called by the framework:
    Code:
    BOOL CFrameWnd::OnCreateClient(LPCREATESTRUCT, CCreateContext* pContext)
    {
    	// default create client will create a view if asked for it
    	if (pContext != NULL && pContext->m_pNewViewClass != NULL)
    	{
    		if (CreateView(pContext, AFX_IDW_PANE_FIRST) == NULL)
    			return FALSE;
    	}
    	return TRUE;
    }
    As you see the one and only one view is created with the ID = AFX_IDW_PANE_FIRST.
    So the
    Code:
    GetDescendantWindow(AFX_IDW_PANE_FIRST, TRUE);
    returns a valid CWnd* pointer that points exactly to the created CView window!
    Victor Nijegorodov

  11. #26
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: Adding Splitter Windows Makes Mainframe Unable to Get Current Document

    Quote Originally Posted by sunnysky View Post
    I am learning MFC while getting familiar with our existing project. Unfortunately our existing project is using this ad-hoc approach.

    Do you know any book teaching the approaches you mentioned?

    Thanks a lot.
    Jeff Prosise's book is still one of the best startup books.
    http://www.amazon.com/Programming-Wi.../dp/1572316950
    It's getting "old" and it doesn't reflect everything new in MFC, but the core of MFC hasn't changed that much. Some of the samples will need a bit of tweaking to get them compliant with the current compilers.


    The thing I'm seeing here... and it's not uncommon is people trying to make MFC do things that don't quite match it's inate concepts. While you can override and overload a lot and there are various places you can hook in to, there's also places where it's very difficult to make MFC do something "different". Learn to embrace the MFC ways and work WITH it. If you try to bend MFC into ways that you think are better, you will find that can take a lot of effort. THe same is true for basic windows concepts btw

  12. #27
    sunnysky Guest

    Re: Adding Splitter Windows Makes Mainframe Unable to Get Current Document

    I think since I override OnCreateClient() in CMainFrame, I need to explicitly call CFrameWnd::OnCreateClient(lpcs, pContext) at the beginning of CMainFrame::OnCreateClient().

    Quote Originally Posted by VictorN View Post
    In my test if I select "MFC Standard" instead of "Windows Explorer"
    the following code is called by the framework:
    Code:
    BOOL CFrameWnd::OnCreateClient(LPCREATESTRUCT, CCreateContext* pContext)
    {
    	// default create client will create a view if asked for it
    	if (pContext != NULL && pContext->m_pNewViewClass != NULL)
    	{
    		if (CreateView(pContext, AFX_IDW_PANE_FIRST) == NULL)
    			return FALSE;
    	}
    	return TRUE;
    }
    As you see the one and only one view is created with the ID = AFX_IDW_PANE_FIRST.
    So the
    Code:
    GetDescendantWindow(AFX_IDW_PANE_FIRST, TRUE);
    returns a valid CWnd* pointer that points exactly to the created CView window!

  13. #28
    sunnysky Guest

    Re: Adding Splitter Windows Makes Mainframe Unable to Get Current Document

    I got this book. But it may not cover point 2 in your post 20.

    Quote Originally Posted by OReubens View Post
    Jeff Prosise's book is still one of the best startup books.
    http://www.amazon.com/Programming-Wi.../dp/1572316950
    It's getting "old" and it doesn't reflect everything new in MFC, but the core of MFC hasn't changed that much. Some of the samples will need a bit of tweaking to get them compliant with the current compilers.


    The thing I'm seeing here... and it's not uncommon is people trying to make MFC do things that don't quite match it's inate concepts. While you can override and overload a lot and there are various places you can hook in to, there's also places where it's very difficult to make MFC do something "different". Learn to embrace the MFC ways and work WITH it. If you try to bend MFC into ways that you think are better, you will find that can take a lot of effort. THe same is true for basic windows concepts btw

  14. #29
    VictorN's Avatar
    VictorN is offline Super Moderator Power Poster
    Join Date
    Jan 2003
    Location
    Hanover Germany
    Posts
    20,395

    Re: Adding Splitter Windows Makes Mainframe Unable to Get Current Document

    Quote Originally Posted by sunnysky View Post
    I think since I override OnCreateClient() in CMainFrame, I need to explicitly call CFrameWnd::OnCreateClient(lpcs, pContext) at the beginning of CMainFrame::OnCreateClient().
    No, if you created the project with AppWizard to add splitter views.
    Victor Nijegorodov

  15. #30
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: Adding Splitter Windows Makes Mainframe Unable to Get Current Document

    Quote Originally Posted by sunnysky View Post
    I got this book. But it may not cover point 2 in your post 20.
    no... that's because accessing the document in the framewnd isn't "normal" behaviour. You should look into why you're trying to do that, and figure out the MFC way out so you don't have to access the document in the framewnd.

Page 2 of 3 FirstFirst 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured