|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
jhaga
|
|
|
|
|
well I guess if you have done it before
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
|
|
|
|
|
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.
|
|
|
|
|
Could you expound on the term "bridge pattern"
Thanks,
Steve
|
|
|
|
|
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
|
|
|
|
|
Brian,
Thanks, that makes sence,
Steve
|
|
|
|
|
Why do you want to reinvent the wheel? why don't you use a property sheet in the wizard mode?
hope this helps...
|
|
|
|
|
Joan,
Sorry to show my ignorance but I am not familiar with property sheets is that part of visual 6 ?
Thanks,
Steve
|
|
|
|
|
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...
|
|
|
|
|
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 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.
|
|
|
|
|
No, a property sheet is not a tab control... well it seems a tab control, but it is not one...
let me explain:
you can add a tab control from your resource editor, but you cannot add a property sheet...
A property sheet is a class that contains property pages (independent dialogs) it can be parametrized in order to look like a installation wizard (as the Installshield...) once a property page is creaetd it persists until you destroy it as it would be a modeless dialog. well, a property page could be understood as a modeless child dialog embedded in the property sheet.
A tab control is not the same because you must hide/show things in a property sheet you have only to change the active page and the dialog (property page) that is intended to be shown will be shown. Each time a dialog gets hidden it doesn't loose any information, it only gets hidden, sothe information persist.
the only thing you should consider is that the pages are not created until you select them (remember that not only the pages can be selected using tabs, you can also parametrize the property sheet to look like a wizard and change from one page to another one using buttons...) in order to avoid that fact, you should create them using the flag PSP_PREMATURE (more in MSDN).
1. If you create a property sheet and you set the wizard mode then tabs are not shown (the pages appear like an installation wizard) (you can change of page using the "next >>" and the "<< back" buttons. (Also, you can hide those buttons and make everything in your way).
2. All the pages are independent dialogs that allow you to handle whatever you want...
3. As all the pages are dialogs, you can be sure that once they have been created they'll be persistent (until you destroy them)...
4. You can add and remove pages dynamically...
5. you can look for watermarks that can be placed as background bitmaps...
6. you can embed property sheets inside other property sheets...
well, I cannot imagine a better scenario to use a wizard... look further the msdn and here in CP to clarify yourself about how to use them.
|
|
|
|
|
Joan,
Okay, I see after doing some searching ( imagine that) it makes sense now.
thanks,
Steve
|
|
|
|
|
Thanks to you, this forum remains great because people ask and others share... you acnnot imagine how many questions I have posted here...
You know: if you need something else we are here...
|
|
|
|
|
|
I have a DLL that is loaded by a framework(I dont have the sourcecode) and I need to determine the process id of the exe(framework) that loaded my dll. It is a standard dll so I have the hinstance/hmodule from the DLL_PROCESS_ATTACH in the dllmain, but have not found a way to determine the process id that is loading the dll. It is possible to have multiple frameworks running so I cant enumerate processes looking for the dll, becuse there may be multiple frameworks running with my dll. I have to determine the PID progamatically within each dll when loaded. Thanks.......
|
|
|
|
|
|
About 3 minutes after submitting my question I found the _getPID() function. DOH!!!!, but thanks for your effort Mike
|
|
|
|
|
Does anyone knows a good tutorial on zooming functions (or how it works) in a CView class?
Thanks,
Ruben
|
|
|
|
|
See SetViewportOrg and SetWindowOrg in the online doc.
|
|
|
|
|
Hello,
I have a solution under VS.net with a dll project and an app project. THe app project uses the dll.
My current way of getting the app to compile is going into project setting for the linking and directing it to the .lib created with the .dll. I then copy the dll from the dll/debug directory to the app/debug directory in order to run the app.
Is there a better way? I could force the dll to be created int the app/debug directory but I want to be sure I am not missing some useful functionality that MS provides in this tool.
Thanks in advance.
KS
|
|
|
|
|
Add 'post build' event handling in the DLL project. Open the properties page for the DLL project and select build events. Select the post-build item. Enter the command line (or lines) you want.
Software Zen: delete this;
|
|
|
|