Bug in CSplitterWnd
-
I have one CSplitterWnd inside my CFrameWnd with 3 rows and one column. In the first two rows are two different CFormViews and in the last row is a new CSplitterWnd with 1 row and 2 columns, which contain a CFormView each. The creation works with the following code in CFrameWnd::OnCreateClient:
// create first splitter wnd m_wndSplitterMain.CreateStatic( this, 3, 1 ) ) m_wndSplitterMain.CreateView( 0, 0, RUNTIME_CLASS(CFunctionsDlg), size, pContext ); // second (in the middle) is playlist dialog m_wndSplitterMain.CreateView( 1, 0, RUNTIME_CLASS(CPlaylistDlg), size, pContext ); // create second splitter wnd (as third pane in first splitter wnd) m_wndSplitterBrowser.CreateStatic(&m_wndSplitterMain, 1, 2, WS_CHILD | WS_VISIBLE, m_wndSplitterMain.IdFromRowCol(2, 0)); // third (on the bottom left) is directory dialog m_wndSplitterBrowser.CreateView(0, 0, RUNTIME_CLASS(CDirectoryDlg), size, pContext); // fourth (on the bottom right) is filelist m_wndSplitterBrowser.CreateView(0, 1, RUNTIME_CLASS(CFilelistDlg), size, pContext);
The problem is, that I use the WM_SIZE messages within the 4 CFormViews to resize the controls, but I don't get a WM_SIZE message for the first two CFormViews (within the first CSplitterWnd), with a safe (GetSafeHwnd() != NULL) handle of the dialog controls of that CFormView. Only the last 2 CFormViews (within the second CSplitterWnd) get correct WM_SIZE messages. Even if I call RecalcLayout( true ); from within CFrameWnd only the last two CFormViews get the WM_SIZE messages. Is that bug already confirmed by Microsoft? What is a workaround for that? Thanks for any help! Konrad -
I have one CSplitterWnd inside my CFrameWnd with 3 rows and one column. In the first two rows are two different CFormViews and in the last row is a new CSplitterWnd with 1 row and 2 columns, which contain a CFormView each. The creation works with the following code in CFrameWnd::OnCreateClient:
// create first splitter wnd m_wndSplitterMain.CreateStatic( this, 3, 1 ) ) m_wndSplitterMain.CreateView( 0, 0, RUNTIME_CLASS(CFunctionsDlg), size, pContext ); // second (in the middle) is playlist dialog m_wndSplitterMain.CreateView( 1, 0, RUNTIME_CLASS(CPlaylistDlg), size, pContext ); // create second splitter wnd (as third pane in first splitter wnd) m_wndSplitterBrowser.CreateStatic(&m_wndSplitterMain, 1, 2, WS_CHILD | WS_VISIBLE, m_wndSplitterMain.IdFromRowCol(2, 0)); // third (on the bottom left) is directory dialog m_wndSplitterBrowser.CreateView(0, 0, RUNTIME_CLASS(CDirectoryDlg), size, pContext); // fourth (on the bottom right) is filelist m_wndSplitterBrowser.CreateView(0, 1, RUNTIME_CLASS(CFilelistDlg), size, pContext);
The problem is, that I use the WM_SIZE messages within the 4 CFormViews to resize the controls, but I don't get a WM_SIZE message for the first two CFormViews (within the first CSplitterWnd), with a safe (GetSafeHwnd() != NULL) handle of the dialog controls of that CFormView. Only the last 2 CFormViews (within the second CSplitterWnd) get correct WM_SIZE messages. Even if I call RecalcLayout( true ); from within CFrameWnd only the last two CFormViews get the WM_SIZE messages. Is that bug already confirmed by Microsoft? What is a workaround for that? Thanks for any help! KonradIn the WM_SIZE handler for your CFrameWnd, you will need to call m_wndSplitterMain.RecalcLayout() and m_wndSplitterBrowser.RecalcLayout().
Software Zen:
delete this;
-
In the WM_SIZE handler for your CFrameWnd, you will need to call m_wndSplitterMain.RecalcLayout() and m_wndSplitterBrowser.RecalcLayout().
Software Zen:
delete this;
So there is no bug in the MFC??? :-D
MSN Messenger. prakashnadar@msn.com Tip of the day of visual C++ IDE. "We use it before you do! Visual C++ was developed using Visual C++"
-
So there is no bug in the MFC??? :-D
MSN Messenger. prakashnadar@msn.com Tip of the day of visual C++ IDE. "We use it before you do! Visual C++ was developed using Visual C++"
Mr.Prakash wrote: So there is no bug in the MFC??? I don't think so. I'll grant you, however, that the
CSplitterWnd
class is difficult to work with. I spent two days this week working on splitter-related problems in an application.
Software Zen:
delete this;
-
Mr.Prakash wrote: So there is no bug in the MFC??? I don't think so. I'll grant you, however, that the
CSplitterWnd
class is difficult to work with. I spent two days this week working on splitter-related problems in an application.
Software Zen:
delete this;
Thanx for a good answer.:) but my question was sarcastic.:-D
MSN Messenger. prakashnadar@msn.com Tip of the day of visual C++ IDE. "We use it before you do! Visual C++ was developed using Visual C++"