C / C++ / MFC

FirstPrevNext

Re: menu driven gui Christian Graus13-Jul-02 3:45 Christian Graus 13-Jul-02 3:45  eng_raju@rediffmail.com wrote: please explain me clearly. Well, it would help if your quesion was clear. You're writing an imaging app ? You don't know how to use a menu, or you don't know how to use OnDraw, or you don't know how to create an enum or a range of const int's ? Christian come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002 Re: menu driven gui Brian Delahunty13-Jul-02 4:18 Brian Delahunty 13-Jul-02 4:18  Christian Graus wrote: You don't know how to use a menu, or you don't know how to use OnDraw, or you don't know how to create an enum or a range of const int's ? Or could it be all. "When a friend hurts us, we should write it down in the sand, where the winds of forgiveness get in charge of erasing it away, and when something great happens, we should engrave it in the stone of the memory of the heart, where no wind can erase it" Nish on life [methinks] "It's The Soapbox; topics are optional" Shog 9 a design question - menu? dlg? or hidden listctrl? ns13-Jul-02 3:05 ns 13-Jul-02 3:05  Which of these three designs would you choose? #2 is a piece of cake. #1 and #3 I am exploring and have the following questions: 1.I've a bunch of options that I will append dynamically as submenus to a top level menu item. Thats doable. Then I want to keep track of which options were selected (setcheck), so that from my long list I now have a subset. Whats the smart way of going about this? I cant very well write handlers or sendmessage on the fly for every item selected in order to add its value to my subset . Like under Color, I have red, green , blue etc. The user selects say five colors. What I want from all this is merely a list of the options that were selected. These menu items dont do anything, except somehow magically add their values to the growing list. Is this reallly simple and I just cant see it? 2.Or should I spawn a modal dialog with a listcontrol with checkboxes instead.(No problem here!) 3.Actually a cool idea suggested was when Color is pressed, a hidden listcontrol shows up (obscuring stuff under it) with the possible options. When you click off it, it vanishes. This listcontrol actually exists on the CFormView but doesnt get shown until the Color button is pressed, and then its supposed to cover up a bunch of other controls also on the CFormView. I have yet to explore this avenue - I can set the listctrl invisible from the properties window easily enough. SO I just have to do something to show it when Color is pressed. MAybe theres a .visible(TRUE) type thing. Anyhoo then I have to utilise a lostfocus type event I suppose, to make it vanish. Thank you if you've read this long post, and I'd appreciate any feedback, ns from "modeless dlg" article by nishant ns13-Jul-02 2:04 ns 13-Jul-02 2:04  I gather you delete (this) in PostNcDestroy(); Fine . I have a button which spawns a modeless dlg when you click, and two and three.... Since I am using the same CModeless * pdlg = new CModeless; for each modeless dlg spawned, the old pdlg gets overwritten when another new gets called on it. So I have three modeless floating around. I click the right hand cross, and PostNcDestroy deletes "this", for any one random modeless dlg. How does this affect the other two pdlg pointers that were created when the new for those two was called? Thanks for clearing this up, ns Re: from "modeless dlg" article by nishant Joaquín M López Muñoz13-Jul-02 2:43 Joaquín M López Muñoz 13-Jul-02 2:43  Unless you've got a good reason for keeping track of the spawned dialog in pdlg you actually needn't do it. As the dialogs take care of themselves by calling delete this on post-destroy time, you can safely let them live their live, and launch them this way: new CModeless; On the other hand, if you keep your code as is, everything will work OK nevertheless --rewriting the value stored at pdlg does not affect in any manner to the dialogs previously created. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo Re: from "modeless dlg" article by nishant Ernest Laurentin13-Jul-02 7:46 Ernest Laurentin 13-Jul-02 7:46  Joaquín, It's always a better idea to keep track of dialogs that you created! It would not be nice to have "multiple" or being able to create "hundreds" of the same dialog just because they are not visible on taskbar or not on top, and the user will lose focus on number of this dialog that he created. This is just to say that it's always better to keep track of them. Last Article: Adding VBScript/JScript to C++ App Re: from "modeless dlg" article by nishant Christian Graus13-Jul-02 12:53 Christian Graus 13-Jul-02 12:53  I raised this with Nish when he posted the article. You need to store your pointers into a vector or ( heaven forbid ) a CArray, so you have them all. Otherwise, you have dangling pointers, and your UI no longer has any control over the dialogs it created. Christian come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002 which class to do registry setting saving/querying in? MDI ns13-Jul-02 1:28 ns 13-Jul-02 1:28  I am going to use the registry saving stuff because when my app starts, the main screen shows up with no data in it (but configured with settings previously saved by user), the app is supposed to go check the registry, and if it finds a database name stored there, things progress, but if not, a CFIleDialog Open pops up. So I gather I''ll be using: RegQueryValue and RegSetValue. Have to set stuff when leaving. Which two places does one save and retrieve from? Which class and which event? I dont have a feel for this yet. thanks, ns Re: which class to do registry setting saving/querying in? MDI Nish Nishant13-Jul-02 1:55 Nish Nishant 13-Jul-02 1:55  Hmmmm, perhaps in your BOOL CWinAppDerived::InitInstance(), just before the creation of the CMainFrame window. Or if you actually want the window up before you read the values, then put them in CMainFrame::OnCreate after all the stuff that's already put there by the App wizard Nish Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW] Thank you! ns13-Jul-02 2:07 ns 13-Jul-02 2:07  Appreciate the info. I'll try it as soon as I figure out what stuff it is that I actually need to save ...something like app size configured by the user, and other details like location on the screen I suppose.Thanks again, ns CFileDialog spawned from doc class ns13-Jul-02 0:49 ns 13-Jul-02 0:49  I have: void CTrain1Doc::OnSelectdatabase() { //CFileDialog fileDlg( TRUE, NULL, NULL, OFN_ALLOWMULTISELECT | OFN_HIDEREADONLY, "All Files (*.*)|*.*||", this); CFileDialog fileDlg(TRUE, NULL, NULL, OFN_HIDEREADONLY|OFN_FILEMUSTEXIST, "Database Files(*.bmp)|*.bmp||",NULL); } The commented out line was the way I saw it in a codeproject sample. But my compiler said it needed a Cwnd* in parameter 6, not a doc *, so I made it NULL. Is this ok? Are there any dangers of saying the parent is NULL? TIA, ns Re: CFileDialog spawned from doc class Nish Nishant13-Jul-02 0:53 Nish Nishant 13-Jul-02 0:53  ns wrote: so I made it NULL. Is this ok? Are there any dangers of saying the parent is NULL? No! It's prefectly okay here. In fact the default value for that parameter is NULL. Nish Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW] Re: CFileDialog spawned from doc class Michael Dunn13-Jul-02 7:09 Michael Dunn 13-Jul-02 7:09  You can also use AfxGetMainWnd() as the parent window. --Mike-- Just released - RightClick-Encrypt v1.3 - Adds fast & easy file encryption to Explorer My really out-of-date homepage Sonork-100.19012 Acid_Helm Menu "Exit" - which class in MDI should handle this COMMAND handler? ns13-Jul-02 0:31 ns 13-Jul-02 0:31  What is in the Exit Command handler? Not EndDialog right? THis is an MDI project. I didnt want to use the standard exit provided in the default menu... Which class shall I associate this Exit item with? View? Doc? or MAinFrame? Thanks, ns Re: Menu "Exit" - which class in MDI should handle this COMMAND handler? Nish Nishant13-Jul-02 0:38 Nish Nishant 13-Jul-02 0:38  What exactly do you want to do with the Menu-Exit handler? The Menu-File-Exit basically posts a WM_CLOSE to the main frame window. So if you want to prompt the user and ask her whether she wants to quit, override WM_CLOSE in your main frame window! Nish Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW] Re: Menu "Exit" - which class in MDI should handle this COMMAND handler? ns13-Jul-02 0:39 ns 13-Jul-02 0:39  Okay! That sounds great! Appreciate it, ns forgot something... ns13-Jul-02 0:40 ns 13-Jul-02 0:40  Do I say DestroyWindow() in the mainframe::onclose()? Thanks, Re: forgot something... Nish Nishant13-Jul-02 0:51 Nish Nishant 13-Jul-02 0:51  ns wrote: Do I say DestroyWindow() in the mainframe::onclose()? No! Just call the base class implementation as in :- void CMainFrame::OnClose() { if(MessageBox("Sure?","?",MB_YESNO)==IDYES) CMDIFrameWnd::OnClose(); } Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW] Re: forgot something... Brian Delahunty13-Jul-02 4:20 Brian Delahunty 13-Jul-02 4:20  Nishant S wrote: ("Sure?","?", Short. Adn to the point. I like it. "When a friend hurts us, we should write it down in the sand, where the winds of forgiveness get in charge of erasing it away, and when something great happens, we should engrave it in the stone of the memory of the heart, where no wind can erase it" Nish on life [methinks] "It's The Soapbox; topics are optional" Shog 9 Re: Menu "Exit" - which class in MDI should handle this COMMAND handler? Ancient Dragon13-Jul-02 0:46 Ancient Dragon 13-Jul-02 0:46  If you look up the ID for that menu handler ID_APP_EXIT on MSDN you will find the answer. It contains a short explanation how many standard menu commands are implemented. ID_APP_EXIT: Exit the application. CWinApp::OnAppExit handles this command by sending a WM_CLOSE message to the application's main window. The standard shutting down of the application (prompting for dirty files and so on) is handled by the CFrameWnd implementation. Customization of this command handler is not recommended. Overriding CWinApp::SaveAllModified or the CFrameWnd closing logic is recommended. If you choose to implement this command, we recommend you use this command ID. HELP!!!!!!!!!!!! MFC is the Best12-Jul-02 23:49 MFC is the Best 12-Jul-02 23:49  Hi @all! I want to use a CDragListBox. I have read inside this forum: First I must make a CListbox with a member variable of the type CListBox. Then I must change the type of the member variable in CDragListBox. My Problem: When I run the programm I got a debug error!!!!! What do I have to still change? Greetings, MFC is the Best Re: HELP!!!!!!!!!!!! Nish Nishant13-Jul-02 0:05 Nish Nishant 13-Jul-02 0:05  What kinda error? Is it crashing? Nish Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW] Re: HELP!!!!!!!!!!!! MFC is the Best13-Jul-02 0:12 MFC is the Best 13-Jul-02 0:12  The programm does not start. After the linking comes the debug error: "Debug Assertion Failed!!" MFC is the Best Re: HELP!!!!!!!!!!!! Nish Nishant13-Jul-02 0:32 Nish Nishant 13-Jul-02 0:32  Okay I am gonna make a guess here, but I think I am gonna back my guess I just added a listbox to a new dialog and associated it with a CDragListBox object, compiled, ran and got the debug assert The problem is that, by default the dialog resource editor will set the LBS_SORT style for the list box control. That's what causing the assert. Take properties and make the Sort property to False, it'll be True by default. Now you won't have the error Regards Nish Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW] Re: HELP!!!!!!!!!!!! MFC is the Best13-Jul-02 0:34 MFC is the Best 13-Jul-02 0:34  Thank you very much! It works......

Last Visit: 31-Dec-99 18:00     Last Update: 19-Jun-24 8:34 Refresh ᐊ Prev1...16599166001660116602166031660416605166061660716608 Next ᐅ

General    News    Suggestion    Question    Bug    Answer    Joke    Praise    Rant    Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.