Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 303
  • Last Modified:

Data and Dialog Programs

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
SGyves
Asked:
SGyves
  • 11
  • 4
  • 2
  • +2
3 Solutions
 
SGyvesAuthor Commented:
Oh yeah....the CPropertySheet would be a derivitive. (i.e. CMyPropertySheet)
0
 
waysideCommented:
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
 
SGyvesAuthor Commented:
Ok....that does sound more along the lines of some good OOP practices.
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
jkrCommented:
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
 
SGyvesAuthor Commented:
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
 
Jaime OlivaresSoftware ArchitectCommented:
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
 
jkrCommented:
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
 
waysideCommented:
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
 
SGyvesAuthor Commented:
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
 
SGyvesAuthor Commented:
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
 
SGyvesAuthor Commented:
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
 
SGyvesAuthor Commented:
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
 
Jaime OlivaresSoftware ArchitectCommented:
>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
 
SGyvesAuthor Commented:
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
 
Jaime OlivaresSoftware ArchitectCommented:
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
 
itsmeandnobodyelseCommented:
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
 
SGyvesAuthor Commented:
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
 
Jaime OlivaresSoftware ArchitectCommented:
In fact you are using a doc/view aproach, although you are not using a doc/view architecture.
0
 
SGyvesAuthor Commented:
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
 
itsmeandnobodyelseCommented:
>> 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
 
SGyvesAuthor Commented:
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

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

  • 11
  • 4
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now