Diff between View, FormView and Dialog???
in [MFC]
|
From: Jimbo_Jimbob_Jiminator on 16 Oct 2008 10:58 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
From: BobF on 16 Oct 2008 11:18 Jimbo_Jimbob_Jiminator 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. > 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 :-))
From: Scott McPhillips [MVP] on 16 Oct 2008 11:20 "Jimbo_Jimbob_Jiminator" <JimboJimbobJiminator(a)discussions.microsoft.com> wrote in message news:0009CA2F-7994-4AE0-9F1F-A33638FE1964(a)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]
From: Joseph M. Newcomer on 16 Oct 2008 14:53 See below... 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. **** 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 **** > >--------------------------------------------------- >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 16 Oct 2008 22:55
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 |