CEditView

grassrootkit

I created an MFC application for SDI. And after everything, I changed the inheritance of my CMyCview class to CEdit View. Compiled, but when I try to execute the application I get an assertion in void CEditView::OnPrepareDC(CDC* pDC, CPrintInfo* pInfo) What are the other things I should do to make my SDI work like a notepad?

grassrootkit

Ok.. I found and replaced all CViews with CEditView. And it's not asserting now. Is it a right way? If it's possible for you to say the sequence of steps I need to do to create a notepad app? I will have a separate class to read/write to a given file path. On Opening a document, I read the text and keep it in a variable. In the OnDraw() function in the view, I keep "SetWindowText()" that read content. Are these enough for a read operation?

grassrootkit

Why this doesn't write anything on the Edit window? CEditViews handle things differently from CView? void CSDITestView::OnDraw(CDC* /*pDC*/) { CSDITestDoc* pDoc = GetDocument(); ASSERT_VALID(pDoc); if (!pDoc) return; CString str = "Hello CEditWorld!"; CEdit& ced = GetEditCtrl(); ced.SetWindowTextA(str); // TODO: add draw code for native data here }

grassrootkit

Damit OnDraw never gets called for CEditViews. :( .. Where I can I find a tutorial that clearly talks about a CEditView ? possibly with a notepad example.

Stuart Dootson

grassrootkit wrote:

Ok.. I found and replaced all CViews with CEditView. And it's not asserting now. Is it a right way?

Yeah, that should now be correctly deriving from CEditView.

grassrootkit wrote:

I will have a separate class to read/write to a given file path.

grassrootkit wrote:

On Opening a document, I read the text and keep it in a variable

You should have read/write operations as methods of your document class, and store the text in a member variable of an instance of your document class (presuming you're using the document/view bits of MFC).

grassrootkit wrote:

In the OnDraw() function in the view, I keep "SetWindowText()" that read content

You should probably do that in the OnUpdate handler - that should get called when the document is updated, by the document calling its UpdateAllViews method (that's part of CView). The idea of the doc/view stuff is for you to put operations affecting the document in your document class, operations affecting the view in your view class, to get separation of concerns.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

Stuart Dootson

Google[^] is your friend[^]

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

grassrootkit

The content in CPP-Home is relatively good. But in all other places, they quickly move on to explain other inherited views. I hate them. I think too few people use SDI,CEdit views in this world :D. Thanks a lot for the explanation & link. I'll try to make use of the doc class. And will come back with another set of questions. :)

grassrootkit

Thanks for your replies again. I've done those changes you suggested. Now the reading part moved to document. but I'm still calling the document's reading functions from the view. Is that ok? Please find below ,In the CmyCView::OnOpen function, CmyCView::OnOpen() { CFileDialog dlg(TRUE,NULL,NULL,NULL,szFilter); CSDITestDoc* pDoc = GetDocument(); if (dlg.DoModal() == IDOK) { pDoc->readFile((LPCTSTR)dlg.GetPathName()); } CString str = pDoc->getText().c_str(); CEdit& ced = GetEditCtrl(); ced.SetWindowTextA(str); } So far so good, some queries regarding the below comment:

Stuart Dootson wrote:

You should probably do that in the OnUpdate handler - that should get called when the document is updated, by the document calling its UpdateAllViews method (that's part of CView).

The only interface between the user & the document object(here a text content) is the CEditview, where the user modifies the text and when he saves, it's going be View->to->Doc. And it's going to be one way. Where does your comment fit in? I can't get the picture.. How does the document get modified by itself so that it updates the view from there? May be you are talking about multiple view? Question No 2: I guessed about a scenario where , as you said the document gets modified from an external window, may be another dialog. So added a dialog. Now I dont have any clue how do I get the document pointer into my Dialog? looks like I'm on the other end of the river..

Stuart Dootson

I've just created a tiny MFC SDI app (using VS2008) to test this out. To hold the text you're editting, I added a member to my document class, plus an accessor function.

public:
CString const& GetText() const { return text_; }
protected:
CString text_;

To read/write a file, I added functionality to the document's Serialize method:

void CdddDoc::Serialize(CArchive& ar)
{
if (ar.IsStoring())
{
ar.Write(text_, text_.GetLength());
}
else
{
const UINT fileSize = (UINT)ar.GetFile()->GetLength();
CStringT<char, StrTraitMFC_DLL<char> > byteString;
ar.Read(byteString.GetBufferSetLength(fileSize), fileSize);
text_ = byteString;
UpdateAllViews(0);
}
}

The byteString stuff is because I had a file with ASCII text, while my app is Unicode, so I need to read the file into a 'byte per char' string and then convert to the standard CString. Then I added an OnUpdate handler to my view, to set the view's text:

void CdddView::OnUpdate(CView* /*pSender*/, LPARAM /*lHint*/, CObject* /*pHint*/)
{
SetWindowText(GetDocument()->GetText());
}

To update the document in line with the edit view, I'd add a method to the document class that would allow me to update the text somehow. So, as you can see, by complying with the standard MFC doc/view framework, I've got plenty of functionality for very little effort!

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

grassrootkit

Thanks a lot for the sample.. I'll try the same in my application.

grassrootkit

Hi Stuart, I've put the logic in ::Serialize function. But how will I connect this function in "Open New file". The control flow is a bit unclear. When I open a document, the first function that gets called is the below one.

The void CMyTestView::OnFileOpen()
{
..

}

Also in the document class, I've got,

BOOL CMyTestDoc::OnOpenDocument()
{
return TRUE;
}

Where should we call the ::Serialize() function?. When I open a new file, what the functions happens/I should call. Can you please..just type down the function names. I'll figure out and end the conversation. Like, Open A new document:

void CMyTestView::OnFileOpen()
{
//Load the file path of the selected file.
}

BOOL CSDITestDoc::OnOpenDocument()
{
return true;
//Call Serialize()
}

void CSDITestDoc::Serialize(CArchive& ar)
{
// read the file
//Update view.
}

grassrootkit

I got a nice example diagram : http://www.informit.com/content/images/bok_0672312417/elementLinks/09fig06.gif[^] But shouldn't that be view's OnFileOpen? It shows as CWinApp::OnFileOpen?

Stuart Dootson

grassrootkit wrote:

But shouldn't that be view's OnFileOpen

Not necessarily - thanks to the wonders of command routing, OnFileOpen can be handled by many different things. The best way to look at whether your view should be handling OnFileOpen is to think about what your view's responsibilities are - display a view of the document and feed back user interactions with that view. Document management (which is what opening a file counts as) isn't really the responsibility of the view. It becomes clearer when you move to MDI, or if you have multiple views on a single document:

An application has zero to many documents
Each document is related to precisely one application, but can have one to many views
Each view is related to precisely one document

HTH!

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

Stuart Dootson

As I've said in my other reply - I think you should probably leave handling OnFileOpen to CWinApp, a) because it fits better with the model of responsibilities and collaborations the MFC doc/view framework was designed around, and b) it fits with MFC, so you don't need to write as much code!

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p