Diff between View, FormView and Dialog???
Jimbo_Jimbob_Jiminator
want tabbed pages. I am looking at using a tabbed control class suggest by
J.Newcomer. The documentation for this (CXTabCtrl on codeproject.com)
discussed putting the tab pages on a form or a dialog.
I went to a doc-view based application so I could easily get a tool bar and
menu from the "Wizard." But, I want tabbed pages. All references to tabbed
pages seem to indicate that they go on a dialog or form. I need to put them
onto a view. I some code that already does this. However, from the previous
post it turns out the implementation is incorrect, although it works.
I have read several articles and web pages. I have an MFC book and a Visual
C++ book that cost $50 each and are both 3-1/2 inches thick. I still can't
get my head around the differences between these concepts.
---------------------------------------------------
From:
http://msdn.microsoft.com/en-us/magazine/cc534994.aspx
With regard to different types of windows, the name form is more expressive
than the name dialog. It describes a window that shows other controls, those
controls containing data. I allow both names, but I prefer form. In fact, in
code you'll see this:
typedef form dialog;
Conceptually, there are only two types of windows: controls and forms.
---------------------------------------------------
So, from this I get that form and dialog are the same thing? The words are
interchangeable? But a FormView is Doc-View architecture?!? So it is
simultaneously a form, a dialog and a view?
I swear I just can't get the concepts. I must be 'freakin' remedial. Call an
institution for me and have me committed. Of all the books out there, someone
could write a book just delving into this area only and cramming it
over-and-over into the readers head. I would pay dearly for it. When I Google
it, I see lot's of similar questions but no answers that I can understand.
Too bad MFC is on the way out; It's not worth an author's time now.
---------------------------------------------------
From:
http://www.openroad.org/school/faq/mfc.html#CViewvsVFormView
Every MFC application has a view class responsible for the program's
appearance. Of the many possible view types, the two most common are:
CView - Used mostly for paint and word-processor style programs. This view
class gives you control over the entire client area, but will require you to
do more work in order to interact with the form, such as creating a button,
and responding to it's click.
CFormView - This is used primarily for forms-based programs, like a
database. This view makes it easy to add controls to a program (like a
button) and respond to their events, but harder to control the client area of
the form.
---------------------------------------------------
OK so, it is harder to control the client area of a form in CFormView than
ia CView. Well because a form and a dialog are the same, this former must
actually equate conceptually to a dialog-view. And, if a form is a dialog and
then what is drawn in the user area of a CView, a window? Nothing? A control?
But, a control is actually a window, correct?
I cannot put tabbed pages onto a CView, correct? I can put tabbed pages on a
CFormView, correct? If these are correct, I still don't understand WHY!!!
Can somebody break this down into a Kinder-garden level explanation? After
that, it may be nap time. Then we get to outside and play in the playground!!
Regards, Jim
BobF
> I posted a structure question the other day where CPropertyPage was used as I
> want tabbed pages. I am looking at using a tabbed control class suggest by
> J.Newcomer. The documentation for this (CXTabCtrl on codeproject.com)
> discussed putting the tab pages on a form or a dialog.
>
> I went to a doc-view based application so I could easily get a tool bar and
> menu from the "Wizard." But, I want tabbed pages. All references to tabbed
> pages seem to indicate that they go on a dialog or form. I need to put them
> onto a view. I some code that already does this. However, from the previous
> post it turns out the implementation is incorrect, although it works.
>
> I have read several articles and web pages. I have an MFC book and a Visual
> C++ book that cost $50 each and are both 3-1/2 inches thick. I still can't
> get my head around the differences between these concepts.
>
Jimxxx -
A fluffy suggestion that might help:
A Form, as in CFormView, is a view. It just so happens that CFormView
displays dialog resources instead of a plain white screen.
Try this:
Create another MFC/SDI/Doc-View project using the Wizard.
Click "Generated Classes" (the bottom choice) in the Wizard dialog.
Change the Base Class from CView to CFormView.
When you click finish, you will be informed that there will be no
Printing support ... click OK
After the Wizard generates the project, go to Resource View/Dialog. You
should see a dialog resource identified as IDD_yourprojectname_FORM.
Put some controls on the form and compile/run.
If I'm understanding what you say you want correctly, then the result
should show something close to what you're after.
If you've already tried this, disregard this post in it's entirety :-))
Scott McPhillips [MVP]
wrote in message news:0009CA2F-7994-4AE0...@microsoft.com...
> I cannot put tabbed pages onto a CView, correct? I can put tabbed pages on
> a
> CFormView, correct? If these are correct, I still don't understand WHY!!!
>
> Can somebody break this down into a Kinder-garden level explanation? After
> that, it may be nap time. Then we get to outside and play in the
> playground!!
>
> Regards, Jim
A CView is for painting your own window, such as graphs or text that you
need to paint yourself. It is an utterly blank slate that you paint on. Do
not use a CView for controls.
Forget "forms." That term is ill-defined in C++ programming.
A dialog template (built in the resource editor by dragging and dropping
controls) is the usual way to display a set of controls. There are at least
two ways to use a dialog template in MFC. One way is to display it in a
CDialog-derived class. Another way is to display it in a CFormView-derived
class. What's the difference? Simple: A dialog pops up over your main
window and can be moved around and closed independently of the main window.
A formview fills your main window (or a portion of it) and cannot be moved
around or closed independently of it.
--
Scott McPhillips [VC++ MVP]
Joseph M. Newcomer
On Thu, 16 Oct 2008 07:58:00 -0700, Jimbo_Jimbob_Jiminator
<JimboJimbo...@discussions.microsoft.com> wrote:
>I posted a structure question the other day where CPropertyPage was used as I
>want tabbed pages. I am looking at using a tabbed control class suggest by
>J.Newcomer. The documentation for this (CXTabCtrl on codeproject.com)
>discussed putting the tab pages on a form or a dialog.
>
>I went to a doc-view based application so I could easily get a tool bar and
>menu from the "Wizard." But, I want tabbed pages. All references to tabbed
>pages seem to indicate that they go on a dialog or form. I need to put them
>onto a view.
****
Which makes CFormView the natural candidate here
****
>I some code that already does this. However, from the previous
>post it turns out the implementation is incorrect, although it works.
>
>I have read several articles and web pages. I have an MFC book and a Visual
>C++ book that cost $50 each and are both 3-1/2 inches thick. I still can't
>get my head around the differences between these concepts.
****
A view is a window manipulated by the document/view framework, and which is coupled to a
document which contains data. One particular *kind* of view is the CFormView, which is
really just a dialog wrapped in a view package so it has all the properties of a view.
There are some interesting issues about CFormView, such as when do you capture the data
from the controls and place it in the document. The two approaches are eager evaluation
and lazy evaluation. Both have their purposes, and sometimes the result is a blend.
In eager evaluation, every time you get a change (EN_CHANGE, CBN_SELENDOK, LBN_SELCHANGED,
BN_CLICKED, etc.) you immediately reflect the new information into the document. You also
call UpdateAllViews if there are more views around because you want the data consistent in
all of them (use a nonzero lHint to handle this case, perhaps encode additional
information in the pHint of UpdateAllViews/OnUpdate).
If you have no other identical views (you have to disable the Window>New menu item!), then
you can get away with lazy evaluation. From time to time the document might want to see
the data, and it will call UpdateAllViews to inform all the views that their data is
needed, and capture it at that point.
A dialog is a prototype for a set of controls arranged in some layout. It can be used to
create a CFormView, a modal dialog, a modeless dialog, or a property page.
If you use the dialog template to create a view, it is a CFormView.
Note that there are specific requirements of these different usages, such as no border,
child window, etc.; if you don't follow these precisely, you will get ASSERT failures
during runtime creation of the pages. The error reporting is rather shoddy at this point,
and you usually have to do some single-stepping to figure out WHICH style you set or
didn't set, which is a real pain.
Typically what I do is create a dialog which has all the controls I want in the view; this
could be as simple as a single tab control that fills the entire dialog, or it could have
other controls on it; what you do depends on the nature of your problem. You can then, in
such a tab control, place OTHER instances of dialog templates by using AddPage. The
parent-child hierarchy is
mainframe
toolbar
dockable menus
status bar
MDI frame
MDI child frame
CFormView (dialog instance)
tab control
page 1 (dialog instance)
page 2 (dialog instance)
...
other controls
You might want to study my locale explorer source to see what I did to make all this work.
Note that all my pages are actually subclasses of a more generic page, so I can share
common subroutines; I place the common subroutines in the parent superclass (such as the
methods that communicate to the parent)
In some apps, I might have many instances of the same dialog in different tabs, for
example, to represent parallel control units in a single embedded device. The CFormView
represents the physical device, the tab control represents each independent control unit
in the device, and some devices can have up to 8 instances of some control units, so I
just use the same dialog each time; when I create it, part of the creation process assigns
the control unit ID# which is unique for each property page.
joe
****
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer
There's no difference in what is going on. These are techniques that wrap a dialog box.
There are minor cosmetic issues on the dialog box if it is being used in one of these
contexts (no caption, thin or no border, child or popup, etc.). The wrappers (CFormView,
modal or modeless dialog, property page, etc.) are just ways of managing instances of
dialog templates.
joe
On Thu, 16 Oct 2008 07:58:00 -0700, Jimbo_Jimbob_Jiminator
<JimboJimbo...@discussions.microsoft.com> wrote:
Jimbo_Jimbob_Jiminator
So further, because a CFormView is just a wrapper to manage a dialog. Then
the terms form a dialog ARE synonymous (as I noted in one of my references)?
So I can say that a CFormView is View based application because it has the
doc-view framework. This framework incorporates the IsModified() and
m_bModified to allow automatic updates of the document from the view and
vice-versa.
However, dialogs typically use DDX and therefore, the full utilization of
the doc-view framework is not realized in FormView. Is that a fair statement?
In fact in the FormView apps I have seen, the data is handled at the control
level. That is, OnSelChange() handler will just take the appropriate action
on a data-pool (structure, class, link-list, etc). There really is no DDX or
IsModified() stuff going on.
Jim
Joseph M. Newcomer
On Fri, 17 Oct 2008 06:31:01 -0700, Jimbo_Jimbob_Jiminator
<JimboJimbo...@discussions.microsoft.com> wrote:
>Thanks Joe,
>
>So further, because a CFormView is just a wrapper to manage a dialog. Then
>the terms form a dialog ARE synonymous (as I noted in one of my references)?
****
Well, it is a bit tricky, because "WinForms" has co-opted the name "form", and uses it in
a way that is consistent with the old VB "Form", both of which are more like dialog-based
apps rather than CFormViews. So, sort-of-kind-of the same. If your CFormView is an SDI
app, it is hard to tell the difference, which is essentially internal behavior (if you
ignore issues such as toolbars and status bars...). An MDI CFormView is much more
powerful, because you can have multiple different CFormViews representing different
documents (and watch out for that Windows>New problem!). A dialog-based app lacks a
toolbar and a status bar unless you do a lot of extra work, but *can* have a menu,
trivially.
****
>
>So I can say that a CFormView is View based application because it has the
>doc-view framework. This framework incorporates the IsModified() and
>m_bModified to allow automatic updates of the document from the view and
>vice-versa.
****
No, the document/view update is a different issue; IsModified deals with document state,
and does not suggest or require that view state and document state may differ or that the
view is or is not permitted to modify the document. The m_bModified flag neither
"allows" or "forbids" updates of the document from the view, and in fact solely and
exclusively deals with whether or not the document itself has been modified, as determined
either by the view remembering to set this value when it modifies a document variable, or
not exposing the document variables and instead supplying methods of the form
void CMyDocument::SetValue(ValueType v)
{
if(value == v)
return;
value = v;
SetModified();
}
or perhaps something even more elaborate (see below). The view would call these Set
functions to set values into the document.
****
>
>However, dialogs typically use DDX and therefore, the full utilization of
>the doc-view framework is not realized in FormView. Is that a fair statement?
****
DDX should be ignored. If you want to get a value to send to the document, go for the
control directly. I do not believe in the use of UpdateData, ever, as an explicit call in
any dialog-related application.
DDX does not set values in the document (although with hand-editing, it could) and would
not set the modified flag. DDX is fully realized in CFormView, I just consider it a
design error to use it. (See my essay on Avoiding UpdateData)
****
>
>In fact in the FormView apps I have seen, the data is handled at the control
>level. That is, OnSelChange() handler will just take the appropriate action
>on a data-pool (structure, class, link-list, etc). There really is no DDX or
>IsModified() stuff going on.
****
That's right. They are an odd hybrid. What you are describing is what I called "eager
evaluation". But DDX is typically ignored in such cases for values, and IsModified is
unrelated to any of this. It only reveals if the document *has been* modified, and has
nothing to do with whether or not it *should be* modified. If, in the process of eager
evaluation, you modify the document, it is your responsibility to call SetModified to tell
the document that its variables have changed. You can ensure this by using the technique
of not exposing the variables, only setter and getter functions, using a setter function
along the lines I showed above.
I also discuss, in my essay on checksums, a way to determine if a value has been set back
to its original state so that the current value set now appears to be identical to the
unchanged value state. You checksum all the state values when the document is read. Each
time you make a change, instead of calling SetModified, you checksum all the values again.
If the checksum you get matches the checksum you stored, the document is now in the same
state it was when it was unmodified (statistically, it is unlikely a checksum will give
the same value for two different states). If the checksums match, you set the modified
flag to FALSE; if the checksums differ, you set the modified flag to TRUE. Upon a save,
you recompute the stored checksum, which represents the new unmodified state. This is
really nice, because it doesn't force a save if the user, for example, clicks and then
unclicks a checkbox, for example.
void CMyDocument::SetValue(Value v)
{
if(value == v)
return;
value = v;
DWORD checksum = ComputeChecksum();
SetModified(checksum != oldchecksum);
}
void CMyDocument::OnSaveDocument()
{
CDocument::OnSaveDocument();
oldchecksum = ComputeChecksum();
SetModified(FALSE);
}
(I *think* I remembered the name of the document's Save handler correctly...but you get
the idea of the intent, at least)
Note that "modified" is therefore a *document* property and should be managed by the
document itself, hence my sketch of the simple-minded approach (which I usually use).
joe
***
Scott McPhillips [MVP]
wrote in message news:5BC92075-215B-460A...@microsoft.com...
> Thanks Joe,
>
> So further, because a CFormView is just a wrapper to manage a dialog. Then
> the terms form a dialog ARE synonymous (as I noted in one of my
> references)?
No, a CFormView is a wrapper to manage a dialog template. A CDialog is also
a wrapper to manage a dialog template. The term "form" is used in other
environment and is not well defined in MFC.
> So I can say that a CFormView is View based application because it has the
> doc-view framework. This framework incorporates the IsModified() and
> m_bModified to allow automatic updates of the document from the view and
> vice-versa.
>
> However, dialogs typically use DDX and therefore, the full utilization of
> the doc-view framework is not realized in FormView. Is that a fair
> statement?
DDX is used identically in CDialog and CFormView.
> In fact in the FormView apps I have seen, the data is handled at the
> control
> level. That is, OnSelChange() handler will just take the appropriate
> action
> on a data-pool (structure, class, link-list, etc). There really is no DDX
> or
> IsModified() stuff going on.
DDX is used identically in CDialog and CFormView. IsModified is a feature
unique to doc/view.
Joseph M. Newcomer
http://www.flounder.com/converting_a_cdialog_to_a_cformview.htm
joe
On Thu, 16 Oct 2008 07:58:00 -0700, Jimbo_Jimbob_Jiminator
<JimboJimbo...@discussions.microsoft.com> wrote:
Jimbo_Jimbob_Jiminator
Right now I have given up on having a CFormView based app with tabbed pages.
I have gone back to a dialog based app. I will add a menu and status bar as
that is not too hard; no tool bar though.
Perhaps once I have that chugging along, I will use the method you
documented to convert it to CFormView.
Jim