View vs. Control - question

Hello all,
this question concerns how a certain app be built - generaly - using MFC.

App's function:
To analyze simple text files that are supposed to obey strict formatting
rules and warn on any mistakes it finds in the files (such as wrong
positioning, expecting to find a number but encoutering a letter instead...
etc.)

So far, a standard MDI app with the "formatting rules" hard-coded inside it
would do. But - The "formatting rules" themselves are several, meaning for
this file the app will operate one set of rules, and for that file - another.

So, I wish the user to operate a different part of the app in order to
create the rules himself. Granting an option for immediate changes, and
future additions.
This made me think of adding a dialog box to my MDI app, in which to include
a special custom control for displaying/editing the "rules".

What I noticed, and what got me wondering and questioning is that -
The View that will be used to display/operate input for my original Doc
(text file being analyzed) is quite similar to the View that this special
custom control should have...
...In the way it will pick up the user's mouse clicks and map them, by their
coordinates, to an object corresponding to the field of letters the user
clicked on,
and also shared OnDraw stuff.

So, after looking up lotsa stuff, to the best of my beginner's
understanding, I am faced with two options:

1) Have 2 Doc types, 2 Views and 2 Doc Templates,
and let the 2 views derive from the same base view that will implement their
shared behavior.
Meaning that afterwards, in my "formatting rules" editing dialog box, I'll
need a control that will display a View (which is not common practice, I
gather, or is it?)

2) Have a custom control that will implement the 2 views' shared behavior,
and derive it to a control in the dialog box and to a View as part of the
MDI in order to display my analyzed text files (using CCtrlView).

Both are a bit of a mystery to me, so I'd appriciate some advice, thoughts
Thanks for whatever reply,
or simply for reading up to here.

As I can see you are concentrating on the design of the application and if you use the inheritance you will always be making a tight couplong and so use the aggregation over inheritance.

As I can understand you are looking for something where you have 2 screens where you see a control that has common behaviour and so put them in one class and derive from it but instead of that use some suitable design pattern to your problem. I have one article regarding it. Design pattern in simple examples. I think the best suited pattern will provide you better solution.