Need advice on a project I may do

[curls8]

I am thinking of doing a project along with learning more about c++. I plan on making a Meal Planner program. I have seen a few but they look like they were down in Visual Basics though they were written in c++. So my question is if I want my program to be user friendly in the end like those how do I go about it? Can I program it first then add graphics or do I do them together? Is there a special book for using those types of grapics in c++ (I want the user to be able to add things, have the program randomly pick a weekly menu at the press of a button, ect...). I hope this isn't to big of a program for me since I am just getting back in it, but I find a learn more when I do projects/practice.

TIA

[weaknessforcats]

All of the fancy doo-dah graphics and windows are just eye candy. They are not functional.

Personally, I would get the program working using the console. All of my funtionality would be in functions that I call and none of these functions would have any code dealing with the user (cin, cout, etc...)

The user would be handled by other functions that contain the necessary cin, cout, etc. These functions would call the functional ones that do the work.

Any displays would be done in functions which call the functions doing the work.

These user functions would not be fancy since their purpose is just to verify the correct operation of the funcitonal functions.

When the functional functions are working, you can construct a graphics program with graphics objects to replace your user functions. Inside there your would call your functional functions.

This is the "front end/back end" type of program. The front end deals with interfacing the user and also interfacing the back end where the actual work is done. This structure allows you to waltz in a new front end (the graphics one) and not have to worry about screwing up the functionality.


This approach will work just fine provided your do not interweave your user interface and your functionality throughout the program.

[newb16]

Is there a special book for using those types of grapics in c++ (I want the user to be able to add things, have the program randomly pick a weekly menu at the press of a button, ect...).
TIA

Graphics is not a part of language or standard library, so you have to choose what platforms your program is intended to run on ( does it need to be portable), is this graphics user interface library have to have free/paid/gpl license, and then choose a book on this concrete library.

[curls8]

Thanks for the replies,

Sorry I took so long to get back. But I was trying to understand the first post answer but i don't think I get it fully. What I am getting is that I should just do the program and then worry about graphics..in other words graphics can always come later....

Like..let say I do a random get week menu function...I make sure that is working and all the rest of my program is and then worry about putting graphics w/ each function I need it to be with.

TIA

[SpecialKay]

yes, you can always do Graphics later. but what hes trying to get across in the first post, is that a project this big needs to be planned properly. If you plan your project using Front/back logic then interlacing the graphic (front) later will be very very simple. If you were to just jump into it and start coding right away, you will have trouble getting the graphics right without messing up the functionallity. If you want to make a really versitile program you should make sure that you have it planned very well before you even open Visual Studio (if thats what you are using)

the basics of Front/back logic is this. you will have a functon that takes no input from the user... nothing, all this function does is process the information passed to it. this part is the back end, because no matter what you change in the front end, the back end, function always does the same processing.

the front end is where you would ask the user for input, and choices. then the front end function would call the back end, and send it the values that the user has selected.

i will try to make up an example.

take your random meal maker. You could have the user select some values:
Time of day,
type of meal (Lunch, dinner ...)
Category ( Pasta, pizza, vegy ...)
this part of the code is where the graphics would be... you could have drop downs or check boxes... what ever.

when you press "go" if calles the back end function that will alway do the same thing regardless of the choices. and that would be randomly pick a meal from the database according to the choises passes from the Front end.


i hope im making sence, and sorry for the type-os... im from quebec.

[oler1s]

What I am getting is that I should just do the program and then worry about graphics..in other words graphics can always come later....

Graphics can come later, but the point is that the code for the user interface, and the code for what your program actually does, are not connected to one another directly. They should be loosely coupled.

Code coupling is a general design issue, and tightly coupled code or poor code architecture is one of the signs of inexperience (or just sheer lack of time and quickly hacked code). The user interface for your program is not directly tied into your program's functionality, so whether it is a graphical interface (GUI), uses the console (CLI), or doesn't even have one, is independent of how your program functions, right? So you can and should write code that isn't intertwined with the interface portion.

Like..let say I do a random get week menu function...I make sure that is working and all the rest of my program is and then worry about putting graphics w/ each function I need it to be with.

It's a bit more than that. Let's say you had a graphical interface. I hit the "Random menu" button. The effect of hitting this button, is probably, that some sort of "signal" is created and stored, or an event is added to a message queue. Then it is up to you to process this signal, or pick out this event from the queue, and process it at your will. There is going to be some coupling at an interface. How each interface registers the various actions, such as adding to a message queue, firing off a event, or signal/slots mechanism, depends on whatever user interface library you use (like Qt, GTK+, Windows API, MFC, etc.).

Whatever happens there, you know that somehow you need to look up all your stored weekly menus, and pick one at random. This functionality is completely independent of the graphical toolkit you have chosen to use (or more generally, the interface you have chosen to create).

[curls8]

Ok..thanks I am understanding a bit more about the graphics. I have found some tutorial sites also that deals with using it in Dev-C++. I can see it will take me at least a month before I start this program.

[oler1s]

As advice: "graphics" is a bit generic and vague. You want your program to have a GUI (graphical user interface). Refer to the term GUI, not graphics.

Also, I very strongly urge you not to work with Dev-C++ anymore. Get Visual C++ Express 2008 and work with that.

[curls8]

As advice: "graphics" is a bit generic and vague. You want your program to have a GUI (graphical user interface). Refer to the term GUI, not graphics.

Also, I very strongly urge you not to work with Dev-C++ anymore. Get Visual C++ Express 2008 and work with that.

Ok thanks. I am downloading it now.