BUG?: CSplitterWnd Mouse Wheel

[Dave Wilson]

The function CSplitterWnd::OnMouseWheel asserts if _any_ pane in the splitter

is not handled by a CScrollView-derived class. This looks like a bug to me;

CSplitterWnd is meant to handle any CView class.


Also, CScrollView itself assumes that if it is part of a splitter, then the

splitter will handle the wheel message (see CScrollView::OnMouseWheel).


In my case, I am using a static splitter with a CTreeView class on the left

(as in Explorer) and a CScrollView class on the right. To avoid the assertion

described above, my CScrollView-derived class must override OnMouseWheel and

must not call the corresponding base class function.


Thinking about it, scrolling messages should be handled by the a dynamic

splitter (since the panes share scroll bars), but not by a static splitter.


So, a possible workaround:


// CMyView is derived from CScrollView

BOOL CMyView::OnMouseWheel(UINT nFlags, short zDelta, CPoint pt)

{

// NOTE: Don't call the CScrollView Implementation because

// it doesn't handle static splitters properly.

// This function improves the CScrollView function,

// ... at least for MFC 4.21 :)


// we don't handle anything but scrolling just now

if (nFlags & (MK_SHIFT | MK_CONTROL))

return FALSE;


// if the parent is a splitter, it will handle the message

CSplitterWnd* pParent = GetParentSplitter(this, TRUE);

if (pParent != NULL &&

(pParent->GetStyle() & SPLS_DYNAMIC_SPLIT))

return FALSE;


// we can't get out of it--perform the scroll ourselves

return CScrollView::DoMouseWheel(nFlags, zDelta, pt);

}