simple k-project

Dave Robbins dmrobbin at
Wed Jul 21 18:44:00 UTC 1999

Hi Jan
The instant I sent off my reply to you saying the web site I wanted to point you to was down, it came back up
here is the site

and here is the text in case the site goes back down.
It's an excellent site but they're reworking it and sometimes it won't come up.
This is written from a M$ VC++ viewpoint but applies very well to kdevelop.


                  Understanding the AppWizard and ClassWizard in Visual C++
                  Version 6.x
                  by Marshall Brain

                  Understanding the Document/View Paradigm

                  The framework that the AppWizard generates revolves around a concept called the
                  Document/View Paradigm. If you understand this paradigm then it is much easier to understand
                  the files that the AppWizard generates, and it also makes it much easier for you to fit your code
                  into the AppWizard framework. This tutorial describes the paradigm so that you completely
                  understand its purpose and intent.

                  The App Wizard takes a document-centric approach to application design. The MFC class
                  hierarchy contains two classes that help to support this approach: CDocument and CView. The
                  AppWizard and MFC use this approach because most Windows applications work this way. Built
                  into any framework generated by the AppWizard is the assumption that your application will want
                  to load and work with multiple documents, and that each document will have one or more views
                  open at a time. This approach makes it extremely easy to create both Single Document
                  Interface(SDI) and Multiple Document Interface(MDI) applications. All applications can be thought
                  of in terms of documents and views.

                  It is easiest to understand the document/view paradigm if you think about a typical MDI word
                  processor like Microsoft Word. At any given time you can have one or more documents open. A
                  document represents a single open file. The user generally has one view open on each document.
                  The view shows the user a part of the document in an MDI window, and lets the user edit the
                  document. However, Microsoft Word allows the user to split a window into multiple frames so that
                  the user can have two or more views on the same document if desired. When the user edits in
                  one of the views, it changes the data in the document associated with the view. If a document has
                  multiple views open and the user changes data in one of the views, the document and all other
                  related views should reflect the change. When the user saves the document, it is that data held by
                  the document that gets saved to disk.

                  Many applications allow the user to open just one type of document. Microsoft Word, for example,
                  works only with Microsoft Word documents. It may allow you to open other types of documents,
                  but it first filters them to turn them into Word documents. Other applications open several different
                  types of documents and can display all of them simultaneously in its MDI framework. Visual C++ is
                  an example of this type of application. The most common type of document Visual C++ works with
                  is a text file that contains code. However, you can open resources in the different resource
                  editors as different types of documents in the MDI framework. Microsoft Works is similar. It can
                  open word processing documents, but it can also open spreadsheet and database documents.
                  Each of these documents has a completely unique view in the MDI frame, but all of the different
                  views live there in harmony with one another. In addition, database documents in Works can be
                  viewed both in a spreadsheet-like list, or in a customizable form that shows one complete record
                  at a time.

                  Therefore, in the most general case, an application may be able to open several different types of
                  documents simultaneously. Each type of document can have a unique viewing window. Any
                  document may have multiple views open at once. In fact, a document might have more than one
                  way of viewing its data, and those different views on a single document might be open
                  simultaneously. Each document stores its data on disk. The views give the user a way to view and
                  edit that data.

                  At a code level, the document and view classes separate functionality. Since this arrangement is
                  typical of most applications, the framework generated by the AppWizard supports this structure
                  implicitly. The document class is responsible for data. It reads the data from a file on disk and
                  holds it in memory. The view class is responsible for presentation. The view takes data from the
                  document class and presents it to the user in a view. The multiple views for a single document
                  synchronize themselves through the data in the document. The MFC class hierarchy contains
                  classes - CDocument and CView - that make this structure easy to create. The AppWizard
                  derives new classes from the existing document and view classes and you build your application
                  within those derived classes.

                  The goal of the document class is to completely encapsulate the data for one open document. It
                  holds the data for the document in a data structure in memory and knows how to load the data
                  from the disk and save it to the disk. The view class uses and manipulates the data in the
                  document based on user events. The view class is responsible for letting the user view the
                  contents of the document. (Note - The document class does not necessarily have to hold its data
                  in memory. In certain types of applications it can act instead as a pipe to a binary file that remains
                  on disk, or to a database.)

                  The relationship between the document and view classes is summarized in the figure below.
                  When you are designing your own applications, you want the document class to completely
                  encapsulate the data, and you want the view class to display information to the user. There should
                  be a clear and obvious way for the view to interact with the document through member functions
                  that you create if you want to properly encapsulate the data in the document.

                  When you create your own application, you typically will create some sort of data structure in the
                  document class to hold the document's data. MFC contains a number of collection classes that
                  you can use for this purpose, or you can create any other data structure that you like. The
                  document class will be called when the data in the data structure needs to be loaded from disk or
                  saved to disk. This is most commonly done through the document class's Serialize function. You
                  will then add your own member functions to the class to encapsulate the data structure and allow
                  the view class to manipulate the data held by the data structure. The view class contains the code
                  to handle user events and draw to the screen.

Jan W. Zumwalt wrote:

> I have had difficulty getting of the ground with a C++ Kdev project. Would some kind soul be willing to send me a ***complete*** project where all they have done is open up a list box, text box, radio button or something simple like that so that I may diasect it!
> I have read the excellent tutorials but none give a complete snapshot in the Kdev environment.
> Thanks so much!
> ---
> Jan W.Zumwalt
> Computer Electronics
> 717 Northway Drive.
> Anchorage, Ak 99508
> V-907-258-1002
> F-907-258-9006
> jan99508 at
> Free web-based email, anytime, anywhere!
> ZDNet Mail -

More information about the KDevelop mailing list