2 CMFCTabControls on different position, but tabs stay on the same place - mfc

I've would like to have 2 sets of tabs on my CScrollView -derived class, so I put 2 CMFCTabCtrs side by side. The tab controls are filled with dialogs (currently same class, but different objects for test purpose, later different dialogs for each tab control).
The problem is while the controls themselves are placed besides each other as desired. the tabs or dialogs from the second tab control appear in area of the first tab controls, thus overlapping with it.
on the picture above the dialog on the left (currently minimalistic for testing) actually belongs to the control on the right. the dialogs inside of tab are childs of the view.
Resource of the dialog:
IDD_COMBATANTDLG DIALOGEX 0, 0, 320, 331
STYLE DS_SETFONT | DS_FIXEDSYS | WS_CHILD | WS_VISIBLE
FONT 8, "MS Shell Dlg", 0, 0, 0x0
BEGIN
GROUPBOX "Flotte",IDC_STATIC,19,18,192,175,BS_FLAT
LTEXT "Static",IDC_STATIC,91,94,19,8
EDITTEXT IDC_EDIT1,136,118,40,14,ES_AUTOHSCROLL
END
declarations:
class SimDataInput : public CScrollView
{
protected: // create from serialization only
SimDataInput();
DECLARE_DYNCREATE(SimDataInput)
// Attributes
private:
CMFCTabCtrl combatant_tabs[2];//tabs
std::vector<CombatantDlg*> p2combatdlg[2];//stores pointers to dialog
const CStringW attdef[2] = { L"Angreifer ", L"Verteidiger " };//standard labels for respective tab controls
............
from OnInitialUpdate():
void SimDataInput::OnInitialUpdate()
{
CScrollView::OnInitialUpdate();
for (auto i = 0; i < 2;i++)
{
CStringW label ( attdef[i]);
RECT pos = RECT{ i * 400, 0, 400 + i * 400, 500 };
combatant_tabs[i].Create(CMFCTabCtrl::STYLE_3D, pos, this,10000+i, CMFCTabCtrl::LOCATION_TOP,TRUE);//create tab
combatant_tabs[i].EnableTabSwap(FALSE);
combatant_tabs[i].EnableActiveTabCloseButton();
//combatant_tabs[sim::ATT].EnableTabDocumentsMenu(TRUE);
p2combatdlg[i].reserve(16);
p2combatdlg[i].emplace_back();//create pointer
p2combatdlg[i].back() = new CombatantDlg(this);//initialize pointer to the new dialog
p2combatdlg[i].back()->Create(IDD_COMBATANTDLG, this);//create dialog
//p2combatdlg[i].back()->SetWindowPos(&combatant_tabs[i], 400, 0, 0, 0, SWP_NOZORDER | SWP_SHOWWINDOW);//tried this -doesn't help
label.AppendFormat(L"%d",1);
combatant_tabs[i].InsertTab(p2combatdlg[i].back(),label , 0, -1, FALSE);//insert the first tab
}
.......
next function inserts new tabs after pushing respective button
void SimDataInput::OnCombatant(UINT nID)//used by ON_COMMAND_RANGE for both tab controls
{
nID -= ID_ATTACKER;
if (combatant_tabs[nID].GetTabsNum() == 16)
return;
CStringW label ( attdef[nID]);
p2combatdlg[nID].emplace_back();
label.AppendFormat(L"%d", p2combatdlg[nID].size());
p2combatdlg[nID].back() = new CombatantDlg(this);
p2combatdlg[nID].back()->Create(IDD_COMBATANTDLG, this);
combatant_tabs[nID].InsertTab(p2combatdlg[nID].back(), label , combatant_tabs[nID].GetTabsNum(), -1, FALSE);
combatant_tabs[nID].SetActiveTab(combatant_tabs[nID].GetTabsNum() - 1);
// TODO: Add your command handler code here
}

After all, making the CMFCTabCtrls parents to the contained dialog corrected the behaviour. I had to store the pointer to the former parentsd insidethe dialogs to make the access easier

Related

Any way to retrieve text height, in pixels, of text within a CEditBox?

I have an edit box that contains text, sometimes many sentences long. The edit box sits at the bottom of its parent dialog (forgive me if I'm saying everything wrong, I don't quite know what I'm doing when it comes to MFC applications). When the dialog that contains my edit box in mind is drawn to the screen, it isn't drawn quite tall enough, and it cuts off a portion of my edit box at the bottom. I was hoping to be able to calculate the height of the text that is used in the edit box, and add a few multiples of that value to the function that determines the height of the parent dialog, for consistency.
I'm not sure if this makes sense, but ultimately I am just trying to find out if it's possible to get text height of text within my edit box. I'm not sure that my fix is even possible given that the edit box is created in a completely different file in the project, but I thought it might be worth asking.
You could calculate the required text height using this basic formula:
CEdit::GetLineCount() * TEXTMETRIC::tmHeight
If the edit control has any of WS_BORDER or WS_HSCROLL styles you have to account for the gap between window size and content size which can be calculated by taking the difference between the heights of the rectangles returned by CEdit::GetWindowRect() and CEdit::GetRect() (thanks Barmak!).
The following is a function to calculate the "ideal" size of an edit control. The returned height is the required window height to fit the content. The returned width equals the original window width. You can use the parameters minLines and maxLines to make sure the returned height is such that the edit control shows at least minLines and at maximum maxLines number of lines without scrolling. Leave them at their defaults to not restrict the height.
CSize GetEditIdealSize( CEdit& edit, unsigned minLines = 0, unsigned maxLines = 0 )
{
if( CFont* pFont = edit.GetFont() )
{
// Get font information.
CClientDC dc( &edit );
auto const pOldFont = dc.SelectObject( pFont );
TEXTMETRICW tm{}; dc.GetTextMetricsW( &tm );
if( pOldFont )
dc.SelectObject( pOldFont );
// Calculate required height for the text content.
int const heightRequired = edit.GetLineCount() * tm.tmHeight;
// Make sure the edit control height stays between the given minimum/maximum.
int idealHeight = std::max<int>( heightRequired, tm.tmHeight * minLines );
if( maxLines > 0 )
idealHeight = std::min<int>( idealHeight, tm.tmHeight * maxLines );
// Get window and content rect.
CRect rcEdit; edit.GetWindowRect( rcEdit );
CRect rcContent; edit.GetRect( rcContent );
// Account for gap between window rect and content rect.
idealHeight += rcEdit.Height() - rcContent.Height();
return { rcEdit.Width(), idealHeight };
}
return {};
}
Use it like this in a member function of the parent window of the edit control to resize the edit control to fit its content:
CSize const idealSize = GetEditIdealSize( m_edit );
m_edit.SetWindowPos( nullptr, 0, 0, idealSize.cx, idealSize.cy, SWP_NOZORDER | SWP_NOACTIVATE | SWP_NOMOVE );
This code has been tested under Windows 10 for an edit control with the style ES_MULTILINE | ES_AUTOVSCROLL | ES_WANTRETURN | WS_BORDER | WS_VISIBLE | WS_CHILD.

Customising a dynamic layout at runtime based on control visibility

I have a multi-purpose CDialog that supports resizing. It can display content in 3 variations.
Variation 1:
Variation 2:
Variation 3:
The dialogue controls are using the dynamic layout settings from the resource editor.
Variation 1 is fine and need no changes.
Variation 2 does not display the combo and date button. As a result I would like the "Text will ..." label to be down at the bottom and the "edit" box to be taller.
Variation 3 has a similar issue where the date button should move to the bottom and the edit box be taller.
Can this be achieved by changing the dynamic layout in code?
Update
I tried this in OnInitDialog:
if (!m_bShowWeekCombo)
{
CRect rctCombo;
m_cbWeek.GetWindowRect(rctCombo);
ScreenToClient(rctCombo);
CRect rctNote;
m_staticInfo.GetWindowRect(rctNote);
ScreenToClient(rctNote);
m_staticInfo.MoveWindow(rctCombo.left, rctCombo.top, rctNote.Width(), rctNote.Height());
}
At first I thought it was working:
The note is now at the bottom. But as soon as I resize the window:
The note has reverted to the original position.
I know I have this answer to a similar issue but do I really have to re-build the whole layout?
Update 2
if (!m_bShowWeekCombo)
{
CRect rctEdit;
m_editText.GetWindowRect(rctEdit);
ScreenToClient(rctEdit);
CRect rctCombo;
m_cbWeek.GetWindowRect(rctCombo);
ScreenToClient(rctCombo);
CRect rctNote;
m_staticInfo.GetWindowRect(rctNote);
ScreenToClient(rctNote);
//m_staticInfo.MoveWindow(rctCombo.left, rctCombo.top, rctNote.Width(), rctNote.Height());
m_staticInfo.SetWindowPos(NULL, rctCombo.left, rctCombo.top, 0, 0,
SWP_NOSIZE | SWP_NOZORDER);
m_editText.SetWindowPos(NULL, 0, 0, rctEdit.Width(), rctEdit.Height() + (rctCombo.top - rctNote.top),
SWP_NOMOVE | SWP_NOZORDER);
if (m_pDynamicLayout)
{
if (!m_pDynamicLayout->HasItem(m_staticInfo.m_hWnd))
{
m_pDynamicLayout->AddItem(m_staticInfo.m_hWnd,
CMFCDynamicLayout::MoveVertical(100), CMFCDynamicLayout::SizeHorizontal(100));
}
else
{
TRACE(L"item already has dynamic move/size\n");
}
if (!m_pDynamicLayout->HasItem(m_editText.m_hWnd))
{
m_pDynamicLayout->AddItem(m_editText.m_hWnd,
CMFCDynamicLayout::MoveNone(), CMFCDynamicLayout::SizeHorizontalAndVertical(100, 100));
}
else
{
TRACE(L"item already has dynamic move/size\n");
}
}
}
When I try the above the control width is the original width, even though the dialog had restored to wider dialog width.
CMFCDynamicLayout reads the dialog resource, it stores the coordinates for the child controls as well as their dynamic resize/move properties.
This is all done in CDialog::OnInitDialog. If you move the child control, example, m_staticInfo then CMFCDynamicLayout doesn't know you moved/resized the control. So upon the next dialog resize request, CMFCDynamicLayout uses the old values.
You can add dynamic resize/move for all controls expcept m_staticInfo and other controls which you intend to move manually. Then add m_staticInfo separately:
BOOL CMyDialog::OnInitDialog()
{
CDialog::OnInitDialog();
CRect rctCombo;
m_cbWeek.GetWindowRect(rctCombo);
ScreenToClient(rctCombo);
m_staticInfo.SetWindowPos(NULL, rctCombo.left, rctCombo.top, 0, 0,
SWP_NOSIZE | SWP_NOZORDER);
if(m_pDynamicLayout)
{
if(!m_pDynamicLayout->HasItem(m_staticInfo.m_hWnd))
{
m_pDynamicLayout->AddItem(m_staticInfo.m_hWnd,
CMFCDynamicLayout::MoveVertical(100), CMFCDynamicLayout::SizeNone());
}
else
{
TRACE(L"item already has dynamic move/size\n");
AfxDebugBreak(0);
}
}
return 1;
}
Internally, MFC calls LoadDynamicLayoutResource(m_lpszTemplateName) to initialize dynamic size/move. But documentation says not to use this method directly.
Clarification
If you are using a dialog that supports resizing then you must remember to calculate the new width and height when you move the control to the new position. You would then use one of the appropriate Size calls. For example:
// The EDIT control height now needs increasing
iNewEditHeight = rctButton.top - iTextMarginY - rctEdit.top;
m_editText.SetWindowPos(nullptr, 0, 0, iNewWidth, iNewEditHeight, SWP_NOMOVE | SWP_NOZORDER);
It is up to you to workout how you want your control initially re-sized.
Then, in OnInitDialog I called a new method:
void CEditTextDlg::SetupDynamicLayout()
{
if (m_pDynamicLayout != nullptr)
{
m_pDynamicLayout->AddItem(IDC_BUTTON_INSERT_DATE,
CMFCDynamicLayout::MoveHorizontalAndVertical(100, 100), CMFCDynamicLayout::SizeNone());
m_pDynamicLayout->AddItem(IDC_STATIC_INFO,
CMFCDynamicLayout::MoveVertical(100), CMFCDynamicLayout::SizeHorizontal(100));
m_pDynamicLayout->AddItem(IDC_EDIT_TEXT,
CMFCDynamicLayout::MoveNone(), CMFCDynamicLayout::SizeHorizontalAndVertical(100, 100));
}
}
If you don't set the width correctly when using SetWindowPos and only use SizeNone() it will not resize correctly.

Create multiple CDockablePanes onto an CDialog

I'm trying to do exactly the same as the article describes here:
"C++ MFC Feature Pack --> Create multiple CDockablePanes onto an CDialog"
I followed his procedure and now am able to undock and move the CDockablePane, but get the same crash when dock it back. In his own answer, he said he created the dummywnd by himself so MFC skipped the creation and the call to GetTopLevelFrame(). And this is where I got confused, how do I create the dummywnd exactly?
My second question is how do I exchange data between the CMyFrame and CDialog?
The person who asked and answered the question seems to be inactive for years and unreachable. Could anyone please help or have any ideas?
Thanks,
Edit:
I break the program and traced back exactly as the other author described. The dummy window mentioned above is actually in afxdragframeimpl.cpp:
void CMFCDragFrameImpl::MoveDragFrame(BOOL bForceMove)
where it creates:
m_pWndDummy = new CDummyDockablePane;
and calls:
m_pWndDummy->CreateEx(0, _T(""), AFXGetTopLevelFrame(m_pDraggedWnd), CRect(0, 0, 0, 0), FALSE, AFX_DUMMY_WND_ID, WS_CHILD);
And yes, I'm trying to create a CFrameWndEx as child window in my dialog, and then add child CDockablePane in that CFrameWndEx.
Basically I have a MFC dialogA with some controls, and within this dialogA I need some tear-off tabsXYZ, and I need to add some controls within each of the tear-off tabsXYZ. So this means each tear-off tabsXYZ is actually one child dialogB. So this comes to where I try to use CDockablePanes (CPaneDialog actually) within the dialogA.
BOOL CMyDlg::OnInitDialog()
{
CRect wndRect;
GetWindowRect(wndRect);
m_pFrame = new CMyFrame();
m_pFrame->Create(NULL, NULL, WS_CHILD | WS_VISIBLE | WS_BORDER, wndRect, this);
m_pFrame->MoveWindow(wndRect);
CDialog::OnInitDialog();
...
}
I don't recommend the above code where frame window is placed in a dialog, because CFrameWndEx does all sorts of strange things, it's easy to break this code. Surprisingly, it works fine on VS2015, I couldn't duplicate any crash. But the window's behavior is still odd.
It's better to make a new frame window, and place a child dialog in frame. For example:
class CMyFrame : public CFrameWndEx
{
CDialog m_dialog;
int OnCreate(LPCREATESTRUCT lpCreateStruct)
{
CFrameWndEx::OnCreate(lpCreateStruct);
m_dialog.Create(IDD_CHILD1, this);
CRect rc;
m_dialog.GetClientRect(&rc);
m_dialog.SetWindowPos(NULL, 0, 0, rc.right, rc.bottom, SWP_SHOWWINDOW);
return 1;
}
DECLARE_MESSAGE_MAP()
};
You open the window as follows:
void CMyMainFrame::OnButton()
{
CMyFrame *frame = new CMyFrame;
frame->LoadFrame(IDR_MAINFRAME,
WS_POPUPWINDOW | WS_THICKFRAME | WS_CAPTION | WS_SYSMENU, this);
frame->SetMenu(0);
frame->ShowWindow(SW_SHOW);
}
You can also create a child dialog and put that inside a docking pane. For example:
class CMyFrame : public CFrameWndEx
{
CDockablePane m_DockWnd;
CDialog m_dialog;
int OnCreate(LPCREATESTRUCT lpCreateStruct)
{
CFrameWndEx::OnCreate(lpCreateStruct);
CMFCVisualManager::SetDefaultManager(RUNTIME_CLASS(CMFCVisualManagerWindows));
CDockingManager::SetDockingMode(DT_SMART);
EnableAutoHidePanes(CBRS_ALIGN_ANY);
m_DockWnd.Create(_T("Test"), this, CRect(0, 0, 200, 200), TRUE, 0,
WS_CHILD | WS_VISIBLE | WS_CLIPSIBLINGS | WS_CLIPCHILDREN |
CBRS_LEFT | CBRS_FLOAT_MULTI);
m_dialog.Create(IDD_PAGE1, &m_DockWnd);
CRect rdialog;
m_dialog.GetClientRect(&rdialog);
m_dialog.SetWindowPos(NULL, 0, 0, rdialog.Width(), rdialog.Height(), SWP_SHOWWINDOW);
m_DockWnd.SetMinSize(rdialog.Size());
m_DockWnd.EnableDocking(CBRS_ALIGN_ANY);
EnableDocking(CBRS_ALIGN_ANY);
DockPane(&m_DockWnd);
return 0;
}
...
};
Also remember, if your main window is also CFrameWndEx then you make something like the following calls in InitInstance:
SetRegistryKey(_T("MyCompany\\MyApp"));
SetRegistryBase(_T("MainFrame"));
When you open a new frame window you must change the registry base with
SetRegistryBase(_T("CMyFrame"));
Then change it back to SetRegistryBase(_T("MainFrame")) when you exit CMyFrame

MFC: how to keep child CWnd dialog from jumping upon resizing the parent window?

I'm writing an MFC dialog with multiple controls. I have currently have a CWnd that is placed on the right half of the dialog. Upon clicking an edit button, the child CWnd is resized to take up a larger portion of the dialog.
However, now when I try to resize the window, the child CWnd jumps back to where it was originally. I cannot seem to figure out how to keep it in it's new position when resizing.
Relevant code:
OnInit() {
//the grouper rectangle
CRect rectHTMLGrouper;
m_grpHTMLbox.GetWindowRect(&rectHTMLGrouper);
ScreenToClient(&rectHTMLGrouper);
//the new rectangle to use for positioning
CRect rectHtml;
rectHtml.left = rectHTMLGrouper.left + PREVIEW_EDITOR_LEFT;
rectHtml.right = rectHTMLGrouper.right - PREVIEW_EDITOR_RIGHT;
rectHtml.top = rectHTMLGrouper.top + PREVIEW_EDITOR_TOP;
rectHtml.bottom = rectHTMLGrouper.bottom - PREVIEW_EDITOR_BOTTOM;
//this inits my editor and sets the position
m_wHtmlEditor.CreateHtmlEditor(rectHTMLGrouper, this, WS_CHILD | WS_VISIBLE | WS_CLIPCHILDREN);
//CodeJock - XTREMEToolkit Call for SetResize Logic
SetResize(m_wHtmlEditor.GetDlgCtrlID(), LEFT_PANE_RESIZE, 0, 1, 1);
m_wHtmlEditor.SetWindowPos(&CWnd::wndTop, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOACTIVATE | SWP_NOMOVE);
}
OnEditMode() {
//enlarge the editor to take up the full dialog
CRect parentClientRect;
m_wHtmlEditor.GetParent()->GetClientRect(&parentClientRect);
m_wHtmlEditor.SetWindowPos(&CWnd::wndTop, parentClientRect.left + edgePadding, parentClientRect.top + editorTopPadding, parentClientRect.right - (edgePadding * 2), parentClientRect.bottom - bottomPadding, SWP_NOOWNERZORDER);
return;
}
Upon clicking an edit button, the child CWnd is resized to take up a
larger portion of the dialog.
You have to handle that same resize in your OnSize() (ON_WM_SIZE()) message handler (using some kind of BOOL member to keep track of the child window's status).
OnSize() is called repeatedly while resizing the dialog.
Example:
// .h
BOOL m_bIsEditMode;
// .cpp
// keep track of m_bIsEditMode
void CMyDlg::OnSize(UINT nType, int cx, int cy)
{
CDialog::OnSize(nType, cx, cy);
if (m_bIsEditMode) {
//enlarge the editor to take up the full dialog
m_wHtmlEditor.MoveWindow (0, 0, cx, cy);
}
}

Having trouble getting a handle to a Dockable Pane C++

I created a multi doc ribbon based MFC application through the MFC Wizard. Im trying to get a handle to m_wndFileView to update its view. I know there are several ways to do it but Im not understanding why the method Im using is not working. Soooo to start
class CMainFrame : public CMDIFrameWndEx
{
...
CFileView m_wndFileView;
CPropertiesWnd m_wndProperties;
...
}
class CFileView : public CDockablePane
{
...
protected:
CViewTree m_wndFileView;
...
};
class CPropertiesWnd : public CDockablePane
{
...
protected:
CMFCPropertyGridCtrl m_wndPropList;
...
};
The main frame is created from MAINAPPLICATION.cpp
// create main MDI Frame window
CMainFrame* pMainFrame = new CMainFrame;
if (!pMainFrame || !pMainFrame->LoadFrame(IDR_MAINFRAME))
{
delete pMainFrame;
return FALSE;
}
m_pMainWnd = pMainFrame;
// call DragAcceptFiles only if there's a suffix
// In an MDI app, this should occur immediately after setting m_pMainWnd
// Enable drag/drop open
m_pMainWnd->DragAcceptFiles();
// Parse command line for standard shell commands, DDE, file open
CCommandLineInfo cmdInfo;
ParseCommandLine(cmdInfo);
// Enable DDE Execute open
EnableShellOpen();
RegisterShellFileTypes(TRUE);
// Dispatch commands specified on the command line. Will return FALSE if
// app was launched with /RegServer, /Register, /Unregserver or /Unregister.
if (!ProcessShellCommand(cmdInfo))
return FALSE;
// The main window has been initialized, so show and update it
pMainFrame->ShowWindow(m_nCmdShow);
pMainFrame->UpdateWindow();
MainFrm.cpp creates these two panes:
// Create file view
CString strFileView;
bNameValid = strFileView.LoadString(IDS_FILE_VIEW);
ASSERT(bNameValid);
if (!m_wndFileView.Create(strFileView, this, CRect(0, 0, 200, 200), TRUE, ID_VIEW_FILEVIEW, WS_CHILD | WS_VISIBLE | WS_CLIPSIBLINGS | WS_CLIPCHILDREN | CBRS_LEFT| CBRS_FLOAT_MULTI))
{
TRACE0("Failed to create File View window\n");
return FALSE; // failed to create
}
// Create properties window
CString strPropertiesWnd;
bNameValid = strPropertiesWnd.LoadString(IDS_PROPERTIES_WND);
ASSERT(bNameValid);
if (!m_wndProperties.Create(strPropertiesWnd, this, CRect(0, 0, 200, 200), TRUE, ID_VIEW_PROPERTIESWND, WS_CHILD | WS_VISIBLE | WS_CLIPSIBLINGS | WS_CLIPCHILDREN | CBRS_RIGHT | CBRS_FLOAT_MULTI))
{
TRACE0("Failed to create Properties window\n");
return FALSE; // failed to create
}
From MAINAPPLICATION.cpp, I can access the properties pane through
CWnd * pwnd = ((CWnd*)(AfxGetApp()->m_pMainWnd));
CPropertiesWnd * pPropertiesWnd = (CPropertiesWnd*)pwnd->GetDlgItem(ID_VIEW_PROPERTIESWND);
CMFCPropertyGridCtrl * m_wndPropList = (CMFCPropertyGridCtrl *)pPropertiesWnd->GetDlgItem(2);
but for some reason I cannot access the fileview pane with
CWnd * pwnd = ((CWnd*)(AfxGetApp()->m_pMainWnd));
CFileView * pFileViewWnd = (CFileView*)pwnd->GetDlgItem(ID_VIEW_FILEVIEW);
CViewTree * m_wndFileView= (CViewTree*)pFileViewWnd ->GetDlgItem(4);
the (CFileView*)pwnd->GetDlgItem(ID_VIEW_FILEVIEW); returns NULL
please help. This is driving me crazy. In the end I can modify the m_wndPropList but not the m_wndFileView because I cannot get a handle to pFileViewWnd. Two panes created in the same way cannot be accessed in the same way. Why? If more code is needed, let me know. Thanks.
You should create a inline getters in CMainFrame class like this:
CFileView& GetFileViewPane()
{
return m_wndFileView;
}
CPropertiesWnd& GetPropsPane()
{
return m_wndProperties;
}
After that you can access those windows just like this:
CMainFrame* pMainFrame = DYNAMIC_DOWNCAST(CMainFrame, AfxGetMainWnd());
if (pMainFrame && pMainFrame->GetSafeHwnd()) // sanity check
{
pMainFrame->GetFileViewPane().DoStuff();
}
So #MarkRansom really helped out with the spy++ idea. To get a handle, I had to do the following:
// get CWnd to main window
CWnd * pwnd = ((CWnd*)(AfxGetApp()->m_pMainWnd));
// from spy++ i found that the tabbed panes were in a window called
// "File View" so i found a child window with that title
HWND h = FindWindowExW(pwnd->GetSafeHwnd(), NULL, NULL, L"File View");
// casted it to a tabbedpane pointer
CTabbedPane * pFileViewWn = (CTabbedPane *)CWnd::FromHandle(h);
// mfc wizard did what seems to me as weird naming. to find the docking
// panes i did the same as above but there was no title to this window
HWND hh = FindWindowExW(pFileViewWn->GetSafeHwnd(), NULL, NULL, L"");
// casted that
CDockablePane* pTabbedBar = (CDockablePane*)CWnd::FromHandle(hh);
// was able to find my specific docking pane using a resource id
CFileView * pFileViewWnd = (CFileView*)pTabbedBar->GetDlgItem(ID_VIEW_FILEVIEW);
// was able to find the control i wanted to use using a resource id
CViewTree * m_wndFileView = (CViewTree *)pFileViewWnd->GetDlgItem(4);
HTREEITEM hRoot = m_wndFileView->GetRootItem();
m_wndFileView->InsertItem(name, 2, 2, hRoot);
Going through the code i would think that the logic would be
tabbed pane
File View Dockable Pane
File View controls
Class View Dockable Pane
Class View controls
but somehow another window slide its way in to make
tabbed pane
MYSTERY DOCKABLE WINDOW
File View Dockable Pane
File View controls
Class View Dockable Pane
Class View controls