Prev: Forcefully Remove USB Flash Drive
Next: SetWindowLongPtr fails when window is subclassed for some cases.
From: Heck on 10 May 2010 01:30
I understand the organization and mechanisms for establishing a
buffer, filling it with structured data and then sending it along,
whether to a device or merely to a program, for, say, display or
storage or for reinterpretation. The data has to be formatted or
delimited in accordance with the requirements of my target. Fine.

When I write an MFC app, let's say without resorting to CArchive and
serialization, I have data within a CDocument and CViews of various
sorts, targets for display and reinterpretation.

So, what do CViews want, in principle? The docs I've read seem to
want me to present the CView with all the data the window could
possibly show, so that a user has as complete an ability to examine
the data as he might ever want. Evidently I need to tell it how to
print the strings in its window. Giving it my buffer is not
sufficient. \n doesn't get me a newline.

Would someone please help me bridge the gap between the organization
and mechanisms of handling structured data and serving it up the way a
CView wants it?

Trying to learn a new trick, this old, cranky software developer is
getting very frustrated and irritated. Thanks. (Originally posted to
microsoft.public.win32.programmer.ui. Forgot to x-post it here.)
From: Alf P. Steinbach on 10 May 2010 02:06
On 10.05.2010 07:30, * Heck:
> I understand the organization and mechanisms for establishing a
> buffer, filling it with structured data and then sending it along,
> whether to a device or merely to a program, for, say, display or
> storage or for reinterpretation. The data has to be formatted or
> delimited in accordance with the requirements of my target. Fine.
>
> When I write an MFC app, let's say without resorting to CArchive and
> serialization, I have data within a CDocument and CViews of various
> sorts, targets for display and reinterpretation.
>
> So, what do CViews want, in principle? The docs I've read seem to
> want me to present the CView with all the data the window could
> possibly show, so that a user has as complete an ability to examine
> the data as he might ever want. Evidently I need to tell it how to
> print the strings in its window. Giving it my buffer is not
> sufficient. \n doesn't get me a newline.
>
> Would someone please help me bridge the gap between the organization
> and mechanisms of handling structured data and serving it up the way a
> CView wants it?
>
> Trying to learn a new trick, this old, cranky software developer is
> getting very frustrated and irritated. Thanks. (Originally posted to
> microsoft.public.win32.programmer.ui. Forgot to x-post it here.)

Think of a spreadsheet that one view presents a grid and as another view
presents as a pie chart graphic, while a third view presents some statistical
analysis.

The MFC CDocument (a.k.a. Model) holds the data, the views display it and allow
the user to modify it.

Read up in Wikipedia on MVC (Model/View/Controller); note that MFC lacks the
controller bit of MVC.


Cheers & hth.,

- Alf
From: ScottMcP [MVP] on 10 May 2010 09:49


The MFC CView class is a blank window, intended for situations where
you want to generate the displayed image yourself. It displays
nothing by itself.

You have to add drawing code in the OnDraw function of your class
derived from CView (or CScrollView). Generally, your OnDraw code will
call GetDocument() and use the returned pointer to access whatever
data you need to do the drawing.

The MFC SCRIBBLE tutorial is an example of this doc/view
relationship. Going through this tutorial might help you. There is a
linked list of line segments stored in the CDocument, and the view
OnDraw draws it.

From: Ulrich Eckhardt on 10 May 2010 11:15
Alf P. Steinbach wrote:
> The MFC CDocument (a.k.a. Model) holds the data, the views display it and
> allow the user to modify it.
>
> Read up in Wikipedia on MVC (Model/View/Controller); note that MFC lacks
> the controller bit of MVC.

I'd have said that the MFC view handles both the view and controller parts
of the MVC-pattern, i.e. that the MFC lacks not the controller but the
distinction between the controller and the view.

Uli

--
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

From: Alf P. Steinbach on 10 May 2010 12:00
* Ulrich Eckhardt:
> Alf P. Steinbach wrote:
>> The MFC CDocument (a.k.a. Model) holds the data, the views display it and
>> allow the user to modify it.
>>
>> Read up in Wikipedia on MVC (Model/View/Controller); note that MFC lacks
>> the controller bit of MVC.
>
> I'd have said that the MFC view handles both the view and controller parts
> of the MVC-pattern,

In MFC the control is distributed spaghetti-like everywhere, like events from
the model; the control is not particularly in the view.


> i.e. that the MFC lacks not the controller but the
> distinction between the controller and the view.

You mean the distinction between the controller and the rest of the system.

It's not a part of the view.

But re the terminology, the controller is an abstraction. The same system can be
modeled and implemented with or without the controller abstraction (or for that
matter views or models). MFC lacks this controller abstraction.

Since the controller is an abstraction it gets pretty silly to mention
abstraction all the time, like saying "lacks the controller /abstraction/".

Hence I wrote just "controller", and I suggest the same for others.


Cheers & hth.,

- Alf
 |  Next  |  Last
Pages: 1 2 3
Prev: Forcefully Remove USB Flash Drive
Next: SetWindowLongPtr fails when window is subclassed for some cases.