MFC: how to fix an MDI after replacing the CView with a CSplitterWnd having two CView-derived classes in the panes - mfc

Question

I added a navigation sidebar in my CChildFrame by creating a CSplitterWnd in it and by adding a CScrollView and a CListView as splitter panes based on this answer. Is there a textbook way to do this? I'm asking because I ran into multiple side-effects like the document name no longer showing up in the applications titlebar or mousewheel no longer working for the CScrollView.
I guess, I need to redirect messages arriving in my CChildFrame somehow to make my CScrollView the default receiver for CView-related messages as the CSplitterWnd breaks the flow, because it's not derived from CView. Can someone point me in the right direction?
(Note: This is still done with VS 2008.)
Update: I just created a separate question for the application window title update issue: MFC: After applying a CSplitterWnd to my CChildFrame the main window title isn't updated any more

Answer 1

These code samples are not the most suitable ones, because they create CWnd-derived panes, not CView-derived ones. The views are not in some way associated to the document. You need to call the CDocument::AddView() method, to add every view you created to the document's list of views. The pContext parameter contains a pointer to the document, among other members.
Put the code below in your document class, to verify that your views have been created and associated to the document correctly:
POSITION pos = GetFirstViewPosition();
while (pos)
{
CView *pVw = GetNextView(pos);
AfxMessageBox(typeid(*pVw).name(), MB_OK | MB_ICONINFORMATION);
}
Also in each view class:
CDocument *pDoc = GetDocument();
if (pDoc) AfxMessageBox(pDoc->GetTitle(), MB_OK | MB_ICONINFORMATION);
else AfxMessageBox("The view has no associated Document!");
Note: The default implementation of the CChildFrame class calls CSplitterWnd::Create() rather than CSplitterWnd::CreateStatic() to create the splitter window, and if you move the splitter window to the end it destroys the panes that come off-view. Then if you move it back it creates them again, using the information in the document template or the existing views. You may need to override this behavior too, if you finally make a dynamic splitter window. Better check the MFC source of the version you are using.

Answer 2

There seem to be historical interferences between splitter and view concerning mouse wheel: https://forums.codeguru.com/showthread.php?42826-BUG-CSplitterWnd-Mouse-Wheel
I wont't mark this as solution, as I don't comprehend the backgrounds completely, but it's a workaround for the moment:
BOOL CMyScrollViewDerivedClassInTheStaticSplitter::OnMouseWheel(UINT nFlags, short zDelta, CPoint pt)
{
// CSplitterWnd prohibits mousewheel somehow. Doing it explicitely here:
CPoint pos = GetScrollPosition();
pos.y -= zDelta;
ScrollToPosition(pos);
return CScrollView::OnMouseWheel(nFlags, zDelta, pt);
}