Solved

Data and Dialog Programs

Posted on 2004-08-10
21
277 Views
Last Modified: 2013-11-20
I have a general question about writing dialog applications. I am currently doing a project that is nothing more than a test wizard that uses a CPropertySheet and a bunch of pages to collect data. I am wondering about the best place to store data. Eventually it will all be written to disk, but the various pages in the CPropertySheet need info from one another and I am trying to figure out the best way to organize that. Should I just use the CPropertySheet, add data members for all of the  data, and store it all there? Just need a little guidence from professionals out there.
0
Comment
Question by:SGyves
  • 11
  • 4
  • 2
  • +2
21 Comments
 

Author Comment

by:SGyves
ID: 11764362
Oh yeah....the CPropertySheet would be a derivitive. (i.e. CMyPropertySheet)
0
 
LVL 14

Assisted Solution

by:wayside
wayside earned 166 total points
ID: 11764458
I would create a separate class to hold all the data, create one object of this class, and pass a pointer or reference of the data class into wherever you need it.

That way the data will also be accessible anywhere else in your program as well, and it will be easy to write/read it from a file.
0
 

Author Comment

by:SGyves
ID: 11764652
Ok....that does sound more along the lines of some good OOP practices.
0
 
LVL 86

Assisted Solution

by:jkr
jkr earned 167 total points
ID: 11764680
Partly agree. Partly, because the data could basically be stored in your CWinApp derived class, which is always and everywhere accessible in your program using 'AfxGetApp()'. Because of this ready made mechanism, I'd prefer the application class over a seperate one.
0
 

Author Comment

by:SGyves
ID: 11764724
I hear you jkr, I thought that might be nice too for that reason, but I hear a lot of people say "stay away from adding too much to the App class". I never knew why that was, I can see why for regular SDI/MDI applications..but for dialog apps...you think that is okay??
0
 
LVL 55

Accepted Solution

by:
Jaime Olivares earned 167 total points
ID: 11764791
I will agree with wayside/jk combined, I would create a data object to store all your data, with proper methods to retreive it.
I would make this object a member of the application class, and access it through the global variable 'theApp'.
Just put:
extern CYourApp theApp;
in all the files you will need access to it.
Maybe you can say: why not to obtain a pointer to the application and don't use a global reference? Because theApp is allways defined in every MFC project, so use it.
 
0
 
LVL 86

Expert Comment

by:jkr
ID: 11764815
Let's say, for *this* data model, it's suitable, since the the only purpose of the application is to collect the data. Using the application class to store the data seems perfect here. Maybe you'd also add a simple abstraction layer by encapsulating the collected data into a struct and just have the application return a reference to that data. If the application class wasn't already there and embedded in the framework, I'd have recommended a singleton or a simple global variable.
0
 
LVL 14

Expert Comment

by:wayside
ID: 11764842
What if you decide you want to reuse the data (and all of the serialization code, manipulations, etc) in another program?

If you just add the data and functions and members of the CWinApp-derived class, it will be a chore to extract all this out to use somewhere else.

Plus, conceptually I think CWinApp is more about managing the GUI and interactions with windows and controls, and this is separate from the data that the program is manipulating. So I try to avoid the temptation to use my CWinApp-derived class as a catch-all container for everything I want to do.

IMO, of course.
0
 

Author Comment

by:SGyves
ID: 11764863
I will probably use a combination...I like the idea of having the data in the app....I will probably make a class instead of a struct to hold the data...just a personal preference...it is a little more work to make the class...but if I want to add data validation functions and such afterwards...a class is the way to go. These are all a big help to me. Hard to figure who deserves the points.
0
 

Author Comment

by:SGyves
ID: 11764882
Exactly why I want to use a class wayside. However, it may not be too bad to make the DataClass a member of the app
0
What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

 

Author Comment

by:SGyves
ID: 11764946
Ok...here is what I am thinking of doing...I have the main app initializing the wizard and a CMyData object (member of the app class) then, I create my property sheet which has a pointer to this data class...now I could just use a function in my app class to get the data pointer when ever I need it...but I would have many AfxGetApp calls in my pages to do this. SO I think the CMyPropertySheet should probably have a pointer to the data and pages that need the data should probably also have a pointer to the main sheet so that data access will be easier. Is this what seems good??
0
 

Author Comment

by:SGyves
ID: 11764967
Or..I could simply have a call to the main app in the pages where I need the data to get the data pointer....that would avoid the unneccessary use of the property sheet for calls.
0
 
LVL 55

Expert Comment

by:Jaime Olivares
ID: 11765107
>now I could just use a function in my app class to get the data pointer when ever I need it...
Have you read my explanation about theApp?
0
 

Author Comment

by:SGyves
ID: 11765343
I see jaime....that sounds good. I have just always tried staying away from using global variables so it was not intuitive to me....but since by nature, VC++ makes the app global...like you said...why not use it.   :)
0
 
LVL 55

Expert Comment

by:Jaime Olivares
ID: 11765412
The advantage over AfxGetApp() is that you don't have to cast to your app object every time you want to use it, nor create a casted pointer to avoid this.
0
 
LVL 39

Expert Comment

by:itsmeandnobodyelse
ID: 11765469
Did you consider a Document-View approach?

There is a document (or model) class between the application and the view (dialog) class that holds data. The dialog would get it's data from document (using a GetDocument() function and appropriate member functions. All data manipulations beside of showing or editing the data is made from document class. The application holds a pointer (or a pointer list if more than one document) to the document and creates the document. However, the app doesn't care about data.

Regards, Alex
0
 

Author Comment

by:SGyves
ID: 11765771
Hi there itsmeandnobodyelse. The only thing about the Doc/View approach is I think that it may be overkill for my particular app. Also, I have already contructed the app as a dialog type app. This thing is just like a little wizard that sequences through pages to collect data. What others have been suggesting here is a type of intermediate object to manipulate and hold data. That seems to fit the best at this point. I am definitely a fan of any situation that lends itself to the D/V architecture...I am just trying to keep this project fast and simple though because there is not much data to be presented...only collected and occasionaly used. Thanks for your input though.
0
 
LVL 55

Expert Comment

by:Jaime Olivares
ID: 11765785
In fact you are using a doc/view aproach, although you are not using a doc/view architecture.
0
 

Author Comment

by:SGyves
ID: 11765848
That is true Jaime!! I noticed that when writing my response to Alex. Anyway...it was hard to split up the points...did it three ways because I thought you all had great suggestions and I appreciate it very much. Thank you all for your expertise. You make me more intelligent by the day.
0
 
LVL 39

Expert Comment

by:itsmeandnobodyelse
ID: 11766045
>> I think that it may be overkill for my particular app

It's the same number of classes:

   CMyApp
         CMyDoc
              CMySpreadsheet

as with

   CMyApp
        CMySpreadsheet          

   CMyData


So, the only difference is, that you don't mix viewing level and data level. So, if you would decide one time to have a WEB interface rather than a dialog it would be easy to change that. You have it right that MFC Document-View is an overkill. But you don't need the factory stuff, messaging and other overhead.

Regards, Alex



0
 

Author Comment

by:SGyves
ID: 11766343
I see what you are saying Alex...and I will consider that option. I value your insight on this project. Thank you.
0

Featured Post

What Is Threat Intelligence?

Threat intelligence is often discussed, but rarely understood. Starting with a precise definition, along with clear business goals, is essential.

Join & Write a Comment

Suggested Solutions

Introduction: Displaying information on the statusbar.   Continuing from the third article about sudoku.   Open the project in visual studio. Status bar – let’s display the timestamp there.  We need to get the timestamp from the document s…
Introduction: Hints for the grid button.  Nested classes, templated collections.  Squash that darned bug! Continuing from the sixth article about sudoku.   Open the project in visual studio. First we will finish with the SUD_SETVALUE messa…
This video will show you how to get GIT to work in Eclipse.   It will walk you through how to install the EGit plugin in eclipse and how to checkout an existing repository.
In this seventh video of the Xpdf series, we discuss and demonstrate the PDFfonts utility, which lists all the fonts used in a PDF file. It does this via a command line interface, making it suitable for use in programs, scripts, batch files — any pl…

746 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

10 Experts available now in Live!

Get 1:1 Help Now