C++/VB - Document/View
Asked By JRGlide
16-Mar-10 03:44 PM
I have a program for viewing point cloud data and I want to add a browse
feature that would allow the user to select multiple data files at once.
When in this mode the program would display the list of files that the user
could either select, or chose a scan mode that would automatically scan
through the list and display the data. This would be implemented as either a
CFormView, or a CView with a floating dialog for the file list and scan
buttons.
My question is I am debating how to best implement the doc/view (or if I
even should). I can see three options:
1. If I keep it as pure doc/view, then the doc would keep the file list and
have to control CList, or dialog and timing controls for the scan feature -
which seems beyond the intention of a document.
2. I could have the document obtain the file list and pass the whole thing
on to the view and have the view control everything, including opening and
closing the files. But this seems to defeat the purpose of doc/view in the
first place.
3. Skip doc/view and just do everything in the view.
I am heavily leaning towards the third option because the first two seem to
use doc/view just for the sake of using it, rather than any valid reason.
But I want to see what you think or maybe there is another option I have not
thought of.
Thank You,
Jim
UpdateAllViews
(1)
CListView
(1)
CTreeView
(1)
CFormView
(1)
CListBox
(1)
CDocument
(1)
CView
(1)
CList
(1)
Joseph M. Newcomer replied to JRGlide
One of the perennial problems of doc/view for CFormView is that the data has two
realities: the controls of the CFormView (or th thhe Tree control of CTreeView or the
list conctrol of a CListView) or the document. Sometimes the right way to approach this
is to treat the data as "virtual", in that if the document actually needs the data, it
calls UpdateAllViews with a nonzero lHint and potentially non-NULL pHint that allow the
view to deliver the data to the document, or have the view that understands the request
call some exposed methods of the CDocument-derived class to send it the current
information. In addition, the "scanng' problem of directories can be incredibly slow if
you look at every file in every directory, so sometimes the technique of "lazy evaluation"
is used, and a subdirectory is not scanned until its node in the tree is expanded,
meaning that at any given instant not even the view has "complete" information available.
More below...
****
Actually, this is completely consistent with the notion of the "document", it is just not
the best approach because there are two copies of reality, and informing the view is
cumbersome (UpdateAllViews is important here!)
****
****
This is the "virtual data" approach I mention above. It is an unfortunate consequence of
the fact that the controls are what the user manipulates. But you man make it be
consistent with doc/view philosophy by having the document shout out to all the views
(UpdateAllViews) "Anyone who has information of interest to me, I want it NOW!"
*****
***
Sometimes this is the simplest approach, but it is dangerous because you can lose track of
who is supposed to be managing the data. Closing a view can have serious negative
consequences. I prefer, in my own code, to avoid this approach and let the document be
the (virtual) repository of the information, even if it has to ask the user interface from
time to time just what is going on here.
****
*****
THis is basically a difficult design decision, and I have found that I favor the
logical-repository approach because it has fewer long-term maintenance consequences than
the other approaches; it works well, but can be a bit clumsy, but provides a uniform
approach to the information management, which to me justifies the extra effort in
establishing the communication protocols between the document and the views.
joe
****
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
JRGlide replied to Joseph M. Newcomer
Right now the viewer is an SDI program so there is only one view, so I do not
need to be concerned about multiple views. Also, since this is only a viewer
the program has no need to write data out. Although that might change in the
future if the user ever wants to save subsets of the data.
As for the scanning process, the user selects the files from a File Open
Dialog that alows multiple selections. These files are then displayed in a
CListBox, so all the files are from one directory.
The user can either select the desired file for viewing, or scan the data
similar to the scan feature on a car radio, where it displays each file a
fixed amount of time as defined by a slider. The reason we are doing this is
that it allows us to easily view a large amount of test data, or play it back
quickly, without having to do multiple file opens.
I present this extra information in case it has a bearing on anyone's opinion.
Thanks,
Jim
Tom Serface replied to JRGlide
For an application like this one you may want to either:
1. Use MDI so you could open and view more than one document at at time.
Even though you are not saving the document the fact that you are reading
2. Allow users to open multiple copies of the program as an SDI program.
That way when they want to view more than one document they can just open a
separate version for each.
The multiple file open idea is interesting, but unless you have a way of
indicating which file the data comes from it may get confusing... just my
opinion.
Tom
JRGlide replied to Tom Serface
Tom,
The multiple files are displayed in a list box. If the user wants to select
a file they just click on it. If they use the scan mode, as the data files
are being displayed the filename is highlighted in the list box, so the user
always knows which file is active.
Tom Serface replied to JRGlide
controlling force", e.g. Automation. . .); if so, changes go to the document, and document uses UpdateAllViews to inform views. UpdateAllViews walks views into the document and each view is responsible for "parsing" the notification (lHint part of the document (to show stuff in the same way between runs), and so, UpdateAllViews stays. If not, if it is completely transitory, then a mechanism of your own choosing operation: model changes, so views need to update. In light of MFC, that means calling UpdateAllViews with "DifferentMark" or whateverr explained by means of lHint and pHint. Goran. ok. I would basically you suggest the Analyzer-classes to be CDocument type classes. Then they could send UpdateAllViews message. I ll think about this. . . . . . I think the current best version with container is we have the Analyze classes: class Analyze { WeatherDocument m_doc; } Then from Analyze we can do UpdateAllViews: m_doc.UpdateAllViews(. . .); to draw at certain point in the middle of Analyzing. This would go to Chart Yes, that would work also maybe. Currently I was thinking just sending the info using UpdateAllViews and not storing it to document. . .but i ll have to think about this. The
have to switch languages in the InitInstance handler. * ** * * ** * Switching the resource which is the SDI CFormView is much harder. What you have to do is create a new CFormView using the new dialog template, attach it to the document, and destroy the original CFormView. Note that you should use UpdateAllViews with a nonzero lHint to tell any existing view to store its control contents in the document, and upon completion, use UpdateAllViews with a different nonzero lHint to tell the form to retrieve any existing data from English ! = 3D id for the main-dialog in German)? Moreover you will need a different CFormView-Class for every language and for every dialogbox? Ok it doesn`t matter how many ShowWindow(SW_SHOW); pOldView-> ShowWindow(SW_HIDE); Or is it better to Destroy the old window? pDoc-> UpdateAllViews(NULL); will only call the active view in a sdi application where only one view added following lines to the code above CDocument *pDoc = pOldView-> GetDocument(); pDoc-> AddView(m_pNewView); pDoc-> UpdateAllViews(pOldView); So there`s first of all the old-view loaded (and the onupdate-method
have used MFC created apps with Doc / View and made my base view class as CFormView. It was convenient and quick, but I was putting all of my data variables in 0.0; m_Invert_Out_1 = 0.0; m_InletNum = 0; / / }}AFX_DATA_INIT } CMyView::~CMyView() { } void CMyView::DoDataExchange(CDataExchange* pDX) { CFormView::DoDataExchange(pDX); / / {{AFX_DATA_MAP(CMyView) DDX_Text(pDX, IDC_Invert_In_1, m_Invert_In_1); DDX_Text(pDX, IDC_Invert_Out_1, m_Invert_Out_1); DDX_Text(pDX, IDC_ItemLabel a reason that it could ever make sense within the context of a dialog or CFormView-derived class. Their only value, which is marginal at best, is for a very limited values in variables in the CDocument-derived class. In the serialize routine I simply call UpdateAllViews() using a specific lHint and pHint value which are not (0, NULL), and when this are managed by the document class, which is where it should be handled. When the CFormView starts up, the OnInitialUpdate loads the controls from the variables in the CDocument-derived class require the CDocument-derived class know about the views, and this is COMPLETELY WRONG!. Use UpdateAllViews to handle the transfer, as described. NEVER include a view header file in the document important, that is how UpdateData is supposed to work). Also, do not forget to call UpdateAllViews upon the change to the document (that is how doc / view is supposed to work
CStatic derived classes for controls I want to paint myself. They are children of a CFormView and all have an OnCtlColor function which returns a brush to paint the background. This doing wrong? Or is there a different way of changing the color? VC MFC Discussions CFormView (1) Check (1) The background (1) El 01 / 03 / 2011 16:57, Frank escribi?: You have to handle the CFormView's OnCtlColor, and there do it. Check http: / / flounder.com / dialog_box_color.htm on how to do it right. Where do you have an OnCtlColor? In the CFormView (which would be wrong) or the control (which is where it belongs). You have not you mean by "change the background color"; do you mean the background color of the CFormView? How do you do that? Note that changing the CFormView background, by any means whatsoever, does NOT cause the controls to be redrawn, and therefore CStatic derived classes for controls I want to paint myself. They are children of a CFormView and all have an OnCtlColor f
the document holds new data for a listcontrol? Is it the right approach to call UpdateAllViews() in the document class? UpdateAllViews(NULL, (LPARAM)VALUES_FROM_DOCUMENT, (CObject *)pData); (with BYTE *pData) These data-packets are coming from my listcontrol. void CMyView::OnUpdate(CView * view, LPARAM lHint, CObject * pHint) { if(lHint = = 0 && pHint = = NULL) { CFormView::OnUpdate(view, lHint, pHint); return; } switch(lHint) { / * lHint * / case CEmvTestDoc::VALUES_TO_DOCUMENT: break; case CEmvTestDoc::VALUES_FROM_DOCUMENT example). I presume this is being called from the document, since nobody else could call UpdateAllViews that way. * ** * * ** * What is the format of the data? If it is just text, then the document holds new data for a listcontrol Is it the right approach to call UpdateAllViews() in the document