Introduction

This article explains the implementation of a simple Doc View framework in a WTL (version 7.5) MDI application. The sample project included with this article is a wizard-generated MDI application enhanced with my framework classes. I enhanced code from Gabriel Kniznik with a little bit closer to the MFC DocView approach, and there exists only one kind of document template - MDI Document template. This framework was written in a week, so I apologize for mistakes and unfinished solutions :).

Implementation

In the demo project, you can see how to integrate the framework to your own project. You have to make changes to CMainFrame, CChildFrame, CYourView, and create a new class CYourDoc. Do not forget to change the IDR_CHILDFRAME string to the form for MFC -> \nDocument\nDVF\n\n\nDVFSimple.Document\nDVF Document.

Share

About the Author

Jozef Božek is currently a software engineer at bring-it-together s.r.o. in area of large scale infomation systems and mobile applications development.
He has been developing in C++ nearly full time since 2000, in Java since 2004 and in Objective-C since 2009. He is programming using Java EE SDK, iOS SDK, COM/DCOM, MFC, ATL, STL and so on

Comments and Discussions

Release Build does not work. When you run the program and create a new doc-view window as soon as you click the mouse left button an error box appears. Using Win XP, VS2008 and VS6.0, errors for both but Debug build works fine!
JS v Wyk

First, I had to do a rather extensive clean up to get rid of common warnings - since they are generated in the headers - they become massive. Please do a UNICODE compile with warning level 4 and 64bit portabilty check using at least a 7.1 version compiler. You'll see what I mean.

Second, I got a memory exception right away in both debug and release build.

This is due to CString class (that will be the WTL implementation) and I guess the use of Ctring for buffer manipulation. My system DEP: /NoExecute=OptIn which is standard. I tried to fix this but soon found out that it's not an easy thing.

My comment:
I think it's a pity you choosed to use CString in your classes. That only makes them less useful in the general case with ATL. For me, CString is OK in MFC but feels odd in ATL - a matter of taste of course - but if you want people to enjoy your work, stick to ATL standard.

Anyway thanks for this since WTL really suffer the lack of a document implementation and a design layout for connection between data and view.

To clarify a little:
The memory exception occurred with a UNICODE build and native wchar_t (/Zc:wchar_t) which is not supported in the original sources. The changes I made was basically adding the _T("some string") macro in some places. An ANSI build works fine - so the above post was maybe a little bit harsh.

It appears that ExtractSubString was coded assuming ANSI . I made a couple of changes as below & added the _T() macros as you said and a few more changes and it compiles with Level 4 & UNICODE. I no longer get the exception you mentioned.

I think that we can re-design to use more templates and put all in one file "atldocview.h", and strip-out any use of STL (you have used std::vector), and then submit to WTL source forge team, to be included in next version of WTL.

WTL does not have CFile or CArchive, and for this reason, I implemented Serializarion partilay.

The Serialization mechanism that I implemented, simple call method Serialization from Document class with the filename and Method (save/load), passing resposability to user to serialize his methods.

This is more flexible than MFC, because developer may want to use boost::serialization, MSXML, iostreams or just implement his serialization mechanism.