C / C++ / MFC

Menu driven console program --- professional suggestion needed.

4-May-03 0:02

Well, almost everything can be done in VB so use it and
go home when you are done. Of course VB is a little bit over-
protective so use MFC(VC) when you need to be in full control
and have time(alot of time!) to learn how to use it right.

But remember that Microsoft is trying to get all of
us people to move on and start using .NET.

jhaga

Re: MFC vs VB

Brian Shifrin4-May-03 2:43

Brian Shifrin

4-May-03 2:43

Depends on type of application you are working on. May be somebody is much better with vb than me....

1) VB6 sucks at code reuse. No such sing as include, and derive your class from existing class from previous project.

2) VB6 can not catch some exceptions. Some exceptions cause vb to crap out.

3) COM: No chance on MTA objects. STA or bust

4) COM: Not every interface is accessible from VB

5) No define macros, I can not survive w/o ASSERT and VERIFY.

6) VB you are stuck with provided UI, subclassing is a pain.
No solution for flicker, etc. Stuck with standard UI: Menus, MDI etc.

Re: MFC vs VB

João Paulo Figueira4-May-03 6:54

João Paulo Figueira

4-May-03 6:54

In a mobile environment such as the PocketPC, it is the difference between a professional application (VC) and a pile of junk (VB). Worst, .NET here, means .NOT (too big, too slow)!

Link26003-May-03 17:17

Link2600

3-May-03 17:17

//This is a console program using C++ language syntax.
//Please reply me in C++ language syntax only.
//Thank you very much.

I have written a GCD program and it is a menu driven program. Below
is a main menu. Instead of always looping back to main menu, I
have designed it so that I could always go back one step. For example,
when I press 1, the program will starts the GCD, after finishing it, I want
it to continue to run, not go back to main. If you copy the code and
run it for yourself, you will see what I mean.

My problem is, I have to put a lot of complicated control code in the
main() function, it is fine for this simple. But when I design a big
complicated program (I'm going to write a converter program), this
technique would not be good. So I wonder how a professional
programmer would design it.(remember: I don't want my program
always going back to main menu.)

main menu:
------------------------------------------------------
Welcome to the Greatest Common Divisor program.
To use the program, please enter one of the following
choices.
1. Start the Greatest Common Divisor (GDC)
2. Learn more about this program
3. Exit the program
>>
--------------------------------------------------------

press 1 and the program will start the GCD:
-------------------------------------------------------
Please enter the first number: 22
Please enter the second number: 44
The GCD is: 22.

Do you want to continue? [Y/N]
>>
---------------------------------------------------------

then if I press 1, the program will start it over again,
but not go back to menu.
----------------------------------------------------------
Please enter the first number:
----------------------------------------------------------

The code is below:
---------------------------------------------------------
#include <iostream>
#include <cstdlib>
#include <conio.h>
using namespace std;

int main_screen();
void GCDstart();
void aboutProgram();

int main()
{
int choice = 0;
while(choice != 3)
{
choice = main_screen();

//Choice 1 to start the GCD
if(choice == 1)
{

while(choice != 'N' && choice != 'n')
{
char choice = 'N';
GCDstart();
cout << "Do you want to continue? [Y/N]" << endl;
cout << ">> ";
cin >> choice;
if(choice == 'Y' || choice == 'y')
{
system("cls");
}
else if(choice == 'N' || choice == 'n')
{
cout << "Program will go back to main menu." << endl;
getch();
system("cls");
break;
}
else
{
cout <<"Input Error:" << endl;
break;
}
}
}

//Choice 2 to learn more about the program
else if(choice == 2)
{
aboutProgram();
}

//Choice 3 to break the loop
else if(choice == 3)
{
break;
}

//Display error
else
{
cout <<"Input Error: please try again!" << endl;
getch();
system("cls");
}

}

cout << "Bye!" << endl;

return 0;
}

int main_screen()
{
//Display choices of the main menu
cout << "Welcome to the Greatest Common Divisor program." << endl
<< "To use the program, please enter one of the following" << endl
<< "choices." << endl
<< "1. Start the Greatest Common Divisor (GDC)" << endl
<< "2. Learn more about this program" << endl
<< "3. Exit the program" <<endl;

get="" user's="" choice
="" int="" choice;
="" cout="" <<="" "="">> ";
cin >> choice;
return choice;
}

///////////////////////////////////////////
//GCD MAIN FUNCTION
void GCDstart()
{
system("cls");
int num_1, num_2;
int remainder = 1, GCD;

cout <<"Please enter the first number: ";
cin >> num_1;
cout <<"Please enter the second number: ";
cin >> num_2;

num_1 = abs(num_1);
num_2 = abs(num_2);

if (num_1 >= num_2)
{

while (remainder != 0)
{
remainder = num_1 % num_2;
num_1 = num_2;
num_2 = remainder;
GCD = num_1;
}
}
else if (num_2 >= num_1)
{
while (remainder != 0)
{
remainder = num_2 % num_1;
num_2 = num_1;
num_1 = remainder;
GCD = num_2;
}
}

cout << "The GCD is: " << GCD <<"." << endl << endl;

}

///////////////////////////////////////////////
//ABOUT PROGRAM FUNCTION

void aboutProgram()
{
system("cls");
cout << "This is a GCD program. It is a program that" << endl;
cout << "finds the Greatest Common Factors. Enter two" << endl;
cout << "integers and the program will tell you the GCD." << endl;
cout << "Please press any key to continue." << endl;
getch();
system("cls");
}

Re: Menu driven console program --- professional suggestion needed.

jhaga4-May-03 1:14

Dialog application opinion needed

4-May-03 1:14

Make each menu it's own function and call
them from a switch body. In this way you
only call the main_menu in main()
and in main_menu you call the next menus etc.

...
cin >> choice;
switch(choice )
{
case 1:
main_menu();
break;
case 2 :
other_menu(); //etc
break;
default :

break;
}

jhaga

Steve Messer3-May-03 15:51

3-May-03 15:51

I am trying to re-create the dialog functionality of a program called myHTPC ( www.myhtpc.net ).

I am new to gui programming so please bare with me. The above mentioned program is coded in Delphi 7 so I image that it uses forms. The functionality that I am trying to reproduce is the following:

The application consists of multiple dialogs ( very possibly many ):

Main Dialog: which can go to a music module and a slide show module. exiting the music or slide show module would bring you back to the main dialog. So with nested dialogs you can always go back to the previous dialog until you get back to the main dialog.

If you go to the music module and play a file then go back to the main dialog then select slide show the music should remain playing.

First off I am looking for theory not code so don't be alarmed. Each dialog would be full screen.

Questions:

1) Would you use a different dialog for each module or dynamically create each module when
selected.
2) Would you destroy each dialog as you create a new one or would you just display the new one
over the top of the previous one.
3) My final question ( for now ) is that of scope. How or where would you instaniate your objects
such that they won't be destroyed if I close the dialog that is controlling it.

Well I hope I explained myself well enough for someone to understand my question. Any advice or pointers would be appreciated.

Thanks,

Steve

jhaga4-May-03 2:17

4-May-03 2:17

Your questions are about implementation but I feel you are still in the design fase. How about a simple prototype to get you going?
You are new to gui programming but have chosen Visual c++?

jhaga

Steve Messer4-May-03 2:50

4-May-03 2:50

jhaga thanks for responding,

Yes, I agree that I am in the design phase and my questions are most definiately about implementation. Sorry, I did not make that more obvious.

I have written a fair amount of the background code. The music module module is mostly written. I wanting to have something working before I tried to make it pretty.

I have always used Visual C++. I use it in the work place. I have always written code but the interface or gui stuff was always written by another team.

Just for information, I have started messing around with GDI+ for drawing. I am not new to programming just new to these gui issues and issues of scope. In my job ( before I got laid off a couple of weeks ago ) I coded aircraft systems for an aircraft simulation company. 9-1l hit the aircraft industry hard.

Let me know if you need more information.

Thanks,

Steve

PS: I started this as a learning experience since I am now looking for a JOB.
I wanted to be more versatile Smile | :)

jhaga4-May-03 3:19

4-May-03 3:19

If I were you I would look at all the source code
at http://www.codeproject.com/dialog/

The gui is usually the easy part of the application Smile | :)

jhaga

Steve Messer4-May-03 3:30

4-May-03 3:30

well I guess if you have done it before Smile | :)

I have looked through the above mentioned section and I don't think that anything there applied to what I am trying to accomplish.

Brian's comment is a start.

Thanks,

Steve

Brian Shifrin4-May-03 2:59

Brian Shifrin

4-May-03 2:59

Application uses single dialog, GDI+ to draw elements. And, I think, it
is much easier and nicer solution than pop dialogs.

>How or where would you instaniate your objects such that they won't
>be destroyed if I close the dialog that is controlling it.

Bridge pattern.

Steve Messer4-May-03 3:27

4-May-03 3:27

Could you expound on the term "bridge pattern"

Thanks,

Steve

Brian Shifrin4-May-03 23:58

Brian Shifrin

4-May-03 23:58

Entire application could be created in 3 - 4 hours of work.

First you create two classes, let's say: CDialogData & CDialogImpl.

CDialogImpl - will be responsible for drawing, CDialogData - dataprovider.

CDialogImpl to expose let's say function CDialogImpl::SetDataProvider

In that case any new screen can be drawn by assigning different Dataprovider and calling SetDataPovider. Application, you mentioned has 3(?) types of objects: buttons & images & textPannel. Each dialog can have different background.

CObjectData: public CObject
{
int nObjectType;
CRect rect;
CString text;
DWORD dwDrawStyle;
}

typedef CList<cobjectdata*, cobjectdata*=""> OBJECT_LIST;

So structure of your CDialogData
{
OBJECT_LIST ObjList;
CBitmap *background;
}

Lifetime of your screen determ by CDialogData....

Brian

Steve Messer5-May-03 5:29

5-May-03 5:29

Brian,

Thanks, that makes sence,

Steve

Joan M4-May-03 22:13

Joan M

4-May-03 22:13

Why do you want to reinvent the wheel? why don't you use a property sheet in the wizard mode?

hope this helps...

Steve Messer5-May-03 5:31

5-May-03 5:31

Joan,

Sorry to show my ignorance but I am not familiar with property sheets is that part of visual 6 ?

Thanks,

Steve

Joan M5-May-03 5:45

Joan M

5-May-03 5:45

Don't ask pardon for asking, we are here to help...

and it is not to be an ignorant not to know what a property sheet is, it's only not knowing what it is...

well, going to the interesting point...

take a look at the CPropertySheet class, it is a container for some other dialogs (CPropertyPages) in a special mode the property sheets can be used as a wizard...

A Property sheet in it's native mode is a property pages container that show tabs (the Microsoft Word options "dialog" is a property sheet with some tabs...). This class can be parametrized in order to look like an assistant/wizard.

Take a look at msdn, you'll see what I'm talking about in a few seconds.

NOTE:
if you think that is the right direction, please feel free to ask whatever you need here in the forums (the property sheets are something very familiar for me...).

Hope this helps...

Steve Messer5-May-03 7:45

5-May-03 7:45

OH,

I have always just refered to them as a tab control. The tab is undesireable in my project.
Is there a way to use them without showing the tab. Not only is the tab undesireable I will have many pages to my project. Each tab "page" will possibly have it's own bitmap background. It seems that property sheet (in my limited understanding) does not lend itself to what I am trying to acomplish. Correct me if I am wrong.

Why do you think that the GDI+ approach mentioned above is reinventing the wheel? Are you familiar with the prject I mentioned above "myHTPC"?

I like the concept of the proptery sheets (tab control), it was actually the first approach I looked into. It doesn't seem to fit ????

Main Menu: Music Module
Slideshow Module
etc

Each module has a main page or tab or property sheet Smile | :)

which has maintanance, options, and setup screens. Each module must persist when its page is no longer active.

Maybe my design is flawed, but that's why I am asking so many questions.

Steve

Knowledge is gained from experience, Experience is gained by making bad decisions.