Diff between View, FormView and Dialog???
in [MFC]
|
From: Jimbo_Jimbob_Jiminator on 17 Oct 2008 09:31 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)? 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" wrote: > I thought of this explanation later... > > 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 > <JimboJimbobJiminator(a)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. 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 > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm >
From: Joseph M. Newcomer on 17 Oct 2008 10:36 See below... On Fri, 17 Oct 2008 06:31:01 -0700, Jimbo_Jimbob_Jiminator <JimboJimbobJiminator(a)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 *** > >Jim > > >"Joseph M. Newcomer" wrote: > >> I thought of this explanation later... >> >> 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 >> <JimboJimbobJiminator(a)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. 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 >> Joseph M. Newcomer [MVP] >> email: newcomer(a)flounder.com >> Web: http://www.flounder.com >> MVP Tips: http://www.flounder.com/mvp_tips.htm >> Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Scott McPhillips [MVP] on 17 Oct 2008 10:41
"Jimbo_Jimbob_Jiminator" <JimboJimbobJiminator(a)discussions.microsoft.com> wrote in message news:5BC92075-215B-460A-9E0C-4670767D28E7(a)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. -- Scott McPhillips [VC++ MVP] |