Adding Splitter Windows Makes Mainframe Unable to Get Current Document

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register or Login
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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()
...

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?

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.

Originally Posted by OReubens

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()
...

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?

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

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

Originally Posted by VictorN

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

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

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

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.