I just started looking at an MFC code of new project, I am assigened to and didn't had much coding done before in MFC. I can see that MFC document view architecture basically assigns all
display related tasks to view, Frame handles communication with windows, and document holds
all application related data.
But then I am wondering why MFC has SetTitle method in CDocument class and not in CFrameWnd class? On the other hand to set text in status bar you got method SetMessageText in CFrameWnd ?
Thanks In advance.
It is already said, that CFrameWnd has a SetTitle method.
But beside that: The reason is simple. A CFrameWnd can contain and serve more than one Document. Depending on the active docucment it should show the title of this determined CDoucment.
And each CDocument can have its own title.
CFrameWnd does have a SetTitle method.
Related
I'm reading Chapter "Drawing with GDI" in book "Programming Windows with MFC".
I saw that CFramewnd or Document/View are used in all examples of this chapter.
I think that maybe CDialog is not proper way to build drawing application.
So, my question is: should I use CDialog or CFramewnd or Docuemnt/View to build drawing application?
And could you give me some difference between CDialog and CFramewnd?
CDialog is intended to be used as the base class for dialogs - relatively shortlived windows to communicate relatively simple bits of information. There are a bunch of standard dialogs (e.g. File Open dialog) but for most information, you'd write your own and base that on CDialog.
So it's not intended as the main window for a normal application. Yet, if your application is a simple tool - say switch a single registry value from 0 to 1 - it may make sense to implement it as just a dialog. But a drawing application? That's not a dialog.
Good afternoon!
I'm updating my application from CMDIFrameWnd to CMDIFrameWndEx, and faced with the problem of client area of MainFrame.Before I had m_hWndMDIClient, and Subclass to it with my class. Now I have m_wndClientArea, and it brings me only headache! Now I can't Subclass. That's why I tried to do this:
mdiCliWnd_.Attach(m_wndClientArea.Detach());
mdiCliWnd_.Invalidate();
mdiCliWnd_.UpdateWindow();
m_wndClientArea.Attach(mdiCliWnd_.Detach());
But I can't even check how it work,because now I have a problem, that I should give CWnd of my client area to another functions, but m_wndClientArea is protected.
So my questions are : Can I subclass my own class in another way? If I can't, how I should use m_wndClientArea to give it to another functions?
What is the reason for that subclassing?
If it is just about drawing the background, use the new virtual function:
OnEraseMDIClientArea
Otherwise it is no problem to use the standard subclassing.
Because the HWND handle of the mdi client window is already attached to a MFC CWnd class object you can't use the MFC subclassing again.
I have a CPropertySheet instance which is initialized using DoModal() in one of the methods of my CDocument class, in an MDI MFC application
My problem is I would like to refresh the view associated with the document from the sheet without ending the DoModal().
How do I get an handle back to the CDocument from my CPropertySheet so I can manipulated the CView easily ?
I have tried different things from this MSDN article but I am not able to retrieve what I want http://msdn.microsoft.com/en-us/library/bs315d2c.aspx
Thanks a lot.
You can use the SendMessage or PostMessage to the target window. Do this when the apply button is clicked.
Refer: http://cppandmfc.blogspot.com/2012/08/mfc-creating-and-using-property-page.html
You will get a Nice idea from that writeup
I have a fairly simple MFC app that just defines its own sub-classes of CDocument, CView and CFrameWnd and uses them via a CSingleDocTemplate to display the read-only contents of the document in a tree on the view. All very standard MFC MVC.
I now need to convert this app so that it works as an ActiveX control that I can then embed it within a larger application.
How should I go about this?
Is it possible to use the COleControl sub-class in place of the CFrameWnd sub-class in the CSingleDocTemplate? Or do I need to place the CFrameWnd sub-class within the COleControl some how?
Failing that, how can I use my existing CDocument\CView sub-classes within an ActiveX control?
Answering my own question: I found quite a few references to an old article about this, which used to be at http://www.microsoft.com/mind/0497/mfc.asp but has long since disappeared. :(
Fortunately though, the Wayback Machine still has a complete copy of it:
"Designing ActiveX Components with the MFC Document/View Model" by Steve Zimmerman, Microsoft Interactive Developer (April 1997)
Steve presents source code for two new classes:
CActiveXDocTemplate : a sub-class of CSingleDocTemplate
CActiveXDocControl : a sub-class of COleControl
which allowed me to use my existing CView and CDocument sub-classes in an ActiveX control.
(Thanks Steve wherever you are now)
I'd like some help on using MFC without the document/view architecture.
I created a project without doc/view support, Visual C++ created a CFrameWnd and a view that inherits from CWnd. I replaced the view inheriting from CWnd with a new view that inherits from CFormView.
However, when I run my program, after I close the window I get a heap corruption error.
If inside where the frame window handles WM_CREATE, you change the code to create the instance of CFormView with the "magic" id of AFX_IDW_PANE_FIRST, you'll find it becomes the view for the frame window. This is due to the behaviour of CFrameWnd::InitialUpdateFrame(), which will be called from within MFC. The MSDN page comments on this helpful little feature:
http://msdn.microsoft.com/en-us/library/ch3t7308.aspx
Since you want to use the dialog editor and you don't want the document/view architecture, then maybe a "Dialog based" application is what you need.
The problem is MFC's lifecycle management. The view declaration (created by Visual C++ wizard) is:
CChildView m_wndView;
I replaced the above code with:
CChildFormView m_wndView;
CChildView inherits from CWnd, CChildFormView inherits from CFormView. Both views were created by the wizard, but only CChildFormView uses the DECLARE_DYNCREATE/IMPLEMENT_DYNCREATE macros.
Since m_wndView is being created in the stack, when MFC automagically calls delete I get the error.