I am trying to create a ListView in MFC C++ in my Child window. I have just finished reading this article on CodeProject. I recommend it to anyone who wants to create the control in a dialog or that has created it already and tries to learn more about it.
Here comes my question! I have to create the ListView control at ::OnCreate() of my ChildWindow. How can I do this?
Here is what I've tried so far:
int CChildFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
if (CMDIChildWnd::OnCreate(lpCreateStruct) == -1)
return -1;
CListCtrl *CarsListView = new CListCtrl();
CarsListView->SetView(LVS_REPORT);
CarsListView->ShowWindow(SW_SHOW);
return 0;
}
(code that is obviously not working...)
There is no Need to use new to create a list view object.
Creating the object doesn't create the window. You Need to call CListView::Create
Maybe you should read a MFC tutorial...
Related
I am new to MFC and have built an "outlook" style MFC app using the wizard. I've extended the CMFCShellTreetCtrl using CMyShellTreeCtrl and had data member variables and all was working fine. Now I want to move the data over to the CDocument class. Since there is several accesses to the data as each item is clicked or enumerated, I thought I would create a member variable m_pDoc to access the public variables in the CDocument. The problem I'm having, I can't find where to get the CDocument as it appears it's not setup when the trees OnCreate is called. That is in OnCreate
CWnd* pWndMain = AfxGetMainWnd();
ASSERT(pWndMain);
ASSERT(pWndMain->IsKindOf(RUNTIME_CLASS(CFrameWnd)) && !pWndMain->IsKindOf(RUNTIME_CLASS(CMDIFrameWnd))); // Not an SDI app.
m_pDoc = (CMyDoc*) ((CFrameWnd*)pWndMain)->GetActiveDocument();
returns NULL in m_pDoc and if I tried in an AfterCreate() (which is called after CreateOutlookBar) it's too late as m_pDoc is already being used and get a crash.
// Create and setup "Outlook" navigation bar:
if (!CreateOutlookBar(m_wndNavigationBar, ID_VIEW_NAVIGATION, m_wndTree, m_wndCalendar, 250))
{
TRACE0("Failed to create navigation pane\n");
return -1; // fail to create
}
m_wndTree.AfterCreate();
Any Ideas?
TIA!!
I came up with the following but I'm not sure if this is the proper way. Again, I'm new to MFC (I always have used Win32 directly). This works so it's AN answer, but is it THE correct answer?
POSITION docpos = AfxGetApp()->GetFirstDocTemplatePosition();
CDocTemplate *doctemplate = AfxGetApp()->GetNextDocTemplate(docpos);
docpos=doctemplate->GetFirstDocPosition();
m_pDoc = (CMyDoc*)doctemplate->GetNextDoc(docpos);
ASSERT(m_pDoc);
ASSERT(m_pDoc->IsKindOf(RUNTIME_CLASS(CMyDoc)));
TIA!!
I'd like to switch between different ribbons for different MDI child frames in my application. I know it's possible with the old style menus, but I can't get it working with the feature pack ribbons.
The code used when it's old style menus:
pDocTemplate = new CMultiDocTemplate(
IDR_MAINFRAME,//Menu to load
RUNTIME_CLASS(CModDoc),
RUNTIME_CLASS(CModFrame), // custom MDI child frame
RUNTIME_CLASS(CdotView));
if (!pDocTemplate)
return FALSE;
AddDocTemplate(pDocTemplate);
pDocTemplate = new CMultiDocTemplate(
IDR_RES_RNGACTIV,//Menu to load
RUNTIME_CLASS(CModRangeDoc),
RUNTIME_CLASS(CModRangeFrame), //custom MDI child frame
RUNTIME_CLASS(CBlankView));
if (!pDocTemplate)
return FALSE;
AddDocTemplate(pDocTemplate);
Another approach I'm thinking of is to unload the current Ribbon and load a new Ribbon from resources?
//Unload ribbon code?
m_wndRibbonBar.LoadFromResource(IDR_RIBBON);
there is no need to have multiple CMFCRibbonBar objects if you don't need to, you can just use the CMFCRibbonBar::LoadFromResource and then you will have to use the CMFCRibbonBar::RecalcLayout method to apply the changes to the User Interface.
Remember to check the return value of CMFCRibbonBar::LoadFromResource to be sure that the load was successful, and it is really important that you call the CMFCRibbonBar::RecalcLayout otherwise you will not see the new ribbon.
I ended up hiding the original ribbonbar and then loading and displaying a new one. Not sure if it's the best way to do it though.
CMultiDocTemplate *pDoc = GetDocTemplate(7);
if (pDoc)
{
CFloorActivDoc* pDocument = (CFloorActivDoc*)pDoc->CreateNewDocument();
CFloorFrame* pFrame = (CFloorFrame*)pDoc->CreateNewFrame(pDocument, NULL);
if (pFrame)
{
pDoc->InitialUpdateFrame(pFrame, pDocument);
m_wndRibbonBar.ShowPane(FALSE, FALSE, TRUE);//Hide original ribbon
m_FloorRibbonBar.Create(this);
m_FloorRibbonBar.LoadFromResource(IDR_RIBBON_FLOORACT);
}
I want to pop-up a dialog for creating a new file in MFC
to collect detail information for a document like Photoshop. (e.g. width, height, depth .)
I found two answers from stackoverflow.
Configuring new document in MFC
MFC, File New with dialog to prompt for paramters and multiple Doc Types?
I want to try the formal one, but I cannot understand the suggestion:
just post a custom message/command to the main frame. Then add a handler that will react by the sequence pop up GUI/update doc/update views. That way, the main frame will be displayed before the GUI is popped up and your user will be happier.
Can anyone explain in detail?
Thanks in advance.
I'm not very sure about the answer you quoted, what I normally do is to pop up the dialog box to collect the new file information in the OnNewDocument() member function -- as the quoted question mentions, it's a bit ugly to put in a UI in the document class, but it works...
BOOL CMyDoc::OnNewDocument()
{ if (!CDocument::OnNewDocument()) // substitute CDocument with your document base class
return FALSE;
CFileNewInfo dlg(AfxGetApp()->GetMainWnd());
// ... set up dialog member variables
if (dlg.DoModal() != IDOK)
return FALSE;
// ... retrieve dialog member variables and update your document appropriately
return TRUE;
}
I have a MFC CDocument and associated CView open in a MDI application. I would like to detach and close the view (and associated frame), while keeping the document open. Looking around the MFC code to see how it does it, reveals the following in CDocument::OnCloseDocument();
// destroy all frames viewing this document
// the last destroy may destroy us
BOOL bAutoDelete = m_bAutoDelete;
m_bAutoDelete = FALSE; // don't destroy document while closing views
while (!m_viewList.IsEmpty())
{
// get frame attached to the view
CView* pView = (CView*)m_viewList.GetHead();
ASSERT_VALID(pView);
CFrameWnd* pFrame = pView->EnsureParentFrame();
// and close it
PreCloseFrame(pFrame);
pFrame->DestroyWindow();
// will destroy the view as well
}
m_bAutoDelete = bAutoDelete;
which I guess I could use in conjunction with CDocument::RemoveView. Is there a better way to approach this than just lifting the MFC source, and is this approach going to cause me other problems or side effects? The project is VS2010 C++.
If you set CDocument::m_bAutoDelete to FALSE (after the document has been created) it should not delete the document when the last view closes.
I'm not sure what you're specifically trying to do but you might want to consider creating a separate 'data' object that can be attached to a document rather than trying to keep the document itself around.
Can someone tell me how I could create a Non Modal Dialog in MFC's Visual c++ 6.0 and show it?
I wrote this code:
CDialog dialog;
if (dialog.init(initialization values...))
dialog.DoModal();
But it blocks my application from showing the dialog. I dont know if there exists any method or other way to do it.
Thanks
/* CChildDialog class is inherited from CDialog */
CChildDialog *m_pDialog = NULL;
// Invoking the Dialog
m_pDialog = new CChildDialog();
if (m_pDialog != NULL)
{
BOOL ret = m_pDialog->Create(IDD_CHILDDIALOG, this);
if (!ret) //Create failed.
{
AfxMessageBox(_T("Error creating Dialog"));
}
m_pDialog->ShowWindow(SW_SHOW);
}
// Delete the dialog once done
delete m_pDialog;
Use CDialog::Create and then use CDialog::ShowWindow. You now have a modeless dialog box.
You can call CDialog::Create and CWnd::ShowWindow like the others have suggested.
Also, keep in mind your dialog will be destroyed right after its creation if it is stored in a local variable.
In this case I find it most convenient to let it self-delete itself to handle the cleanup.
Often it's considered bad form to make "implicit" memory freeing from within a class, and not by what it created it, but I usually make exceptions for modeless dialog boxes.
That is;
Calling code:
#include "MyDialog.h"
void CMyApp::OpenDialog()
{
CMyDialog* pDlg = new CMyDialog(this);
if (pDlg->Create(IDD_MYDIALOG, this))
pDlg->ShowWindow(SW_SHOWNORMAL);
else
delete pDlg;
}
Dialog code:
void CMapBasicDlg::OnDestroy()
{
CDialog::OnDestroy();
delete this; // Shown as non-modal, we'll clean up ourselves
}
You need to call CDialog::Create instead. You will need to call DestroyWindow when you are finished with the dialog. You might also need to pass dialog messages onto the object but I can't remember if MFC handles this for you or not.
DoModal is blocking. You have to create your dialog on the heap or make it a member of your class (this is important), call Create then call ShowWindow.