C / C++ / MFC

FirstPrevNext

CreateDialogIndirect doesn't return CHAIGNEAU27-May-03 1:40 CHAIGNEAU 27-May-03 1:40  I have a dialog box with a property sheet and 2 property pages. In my property page I have a button. When I push this button, I want to show a dialof. But the call to CreateDialogIndirect during the domodal doesn't return and my app is blocked. Any ideas ? Re: CreateDialogIndirect doesn't return Rage27-May-03 5:33 Rage 27-May-03 5:33  CHAIGNEAU wrote: doesn't return What do you mean ? Is the dialog box displayed ? How do you dismiss it ? Or does your program hang when doing the CreateDialogIndirect ? If yes, is it working if you use DoModal() isntead of starting it with CreateDialogIndirect() ? ~RaGE(); Re: CreateDialogIndirect doesn't return Rage27-May-03 5:36 Rage 27-May-03 5:36  If your app hangs, maybe you have forgotten to use ShowWindow(SW_SHOW); to show your dialog, since this is not automatically done by the CreateDialogIndirect() function. ~RaGE(); Re: CreateDialogIndirect doesn't return CHAIGNEAU27-May-03 9:30 CHAIGNEAU 27-May-03 9:30  I instantiate a dialog and then call domodal. Domodal call CreateDialogIndirect() and my program hang. I have found the reason : I must modify the ex style of my propertysheet to put WS_EX_CONTROLPARENT. I have found in the MSDN an article wich describe this problem. Thanx to all. Problems with message routing in Dundas' COXSizeControlBar Miguel Segarra27-May-03 1:21 Miguel Segarra 27-May-03 1:21  I have a problem using COXSizeControlBar from Dundas Ultimate Toolbox 7.5. I have a COX3DTabViewContainer object inside a class derived from COXSizeControlBar. The tab control has two tabs and in one tab there is a COXShorcutBar object, in the other tab there is a CTreeControl object. The problem is that when I use message handlers inside the class derived from COXSizeControlBar, the message handler gets called and processed but when the message returns to the control that originated the message (e.g. the tree control) the return value is always 0 (the value pointed by the LRESULT parameter of the message handler) even if I change the value in the message handler. It is not possible for me then to cancel the editing of a tree control item label (for instance). Have anybody found this problem yet? I have modified and example from Dundas which exactly does this and IT DOES NOT WORK? I guess it is a problem either with the message routing of the COXSizeControlBar or the COX3DTabViewContainer but I haven't been able to find it yet? Thanks in advance, Miguel Re: Problems with message routing in Dundas' COXSizeControlBar Ivor S. Sargoytchev27-May-03 5:36 Ivor S. Sargoytchev 27-May-03 5:36  Miguel, Can you send me the sample you created to reproduce this problem? I will try to fix it and send you the updated ToolBox files. Ivor S. Sargoytchev Dundas Software Re: Problems with message routing in Dundas' COXSizeControlBar Ivor S. Sargoytchev28-May-03 10:12 Ivor S. Sargoytchev 28-May-03 10:12  Miguel, The problem that you encountered is not in Ultimate ToolBox's COXSizeControlBar, but it is in the way MFC handles notify messages in grand parent windows. If you construct a small dialog based application that has a tab control and you add a tree as a child window of the tab control, you will find the same problem - handling TVN_BEGINLABELEDIT in the dialog and returning TRUE will not prevent a label from being edited. The solution to this problem if to handle the TVN_BEGINLABELEDIT either in a derived class or a parent window class - but not in a grand parent. Ivor S. Sargoytchev Dundas Software Re: Problems with message routing in Dundas' COXSizeControlBar Miguel Segarra28-May-03 23:09 Miguel Segarra 28-May-03 23:09  Igor, I think I do not understand what you say in your mail. In the Dundas example I sent you, there are the following window classes: CMainFrame ----> grandparent of CTreeCtrl data member C3DTabViewBar----> parent of CTreeCtrl data member CTreeCtrl ----> child In your mail you say the TVN_BEGINLABELEDIT message should be handled either in a derived class (of CTreeCtrl I guess you mean) or in the parent window class (C3DTabViewBar which is derived from COXSizeControlBar). Well, in the example I sent you the TVN_BEGINLABELEDIT message handler is placed in the parent window (the C3DTabViewBar) and the message in not handled properly (as you can see in the example I sent you). As you say if you try to handle the message in the grand parent window (CMainFrame) it also doesn´t work (which I tried before). From your mail, i guess you have another example that does not work but, do you please have an example that works with the COXSizeControlBar? I need to solve this problem and it will save a lot of time to me if you already have a solution for this. ¿Can you clarify to me what you say in your mail? If I understand right, the example I sent you should work and it doesn´t. I also tried to handle the message in CMainFrame and it also does not work. Best Regards and thanks for the help, Miguel Re: Problems with message routing in Dundas' COXSizeControlBar Ivor S. Sargoytchev29-May-03 7:53 Ivor S. Sargoytchev 29-May-03 7:53  Miguel, In the example that you sent me the member m_treeClass of type CTreeCtrl if a child of m_TabViewContainer of type COX3DTabViewContainer which is a child of m_3DTabViewBar of type C3DTabViewBar. Therefore m_3DTabViewBar is a grand parent of m_treeClass and you are handling your TVN_BEGINLABELEDIT message in C3DTabViewBar. Just make m_treeClass a child of m_3DTabViewBar and you will see - the message is handled properly. Ivor S. Sargoytchev Dundas Software Re: Problems with message routing in Dundas' COXSizeControlBar Miguel Segarra30-May-03 1:26 Miguel Segarra 30-May-03 1:26  Dear Ivor, First of all I apologize for calling you Igor in my first message (it is a more common name to me). Secondly, I manage to get the application working with the tips you gave me. Nevertheless, I still do not fully understand how the thing is working. In my application I set the parent of the tree ctrl to the COXSizeControlBar class (m_wndTree.Create(pParentWnd... where pParentWnd is a pointer to an object of a class derived from COXSizeControlBar). After this I created the tab control as a child of the COXSizeControlBar class and added the tree control to a page of the tab control. Then it was possible to handle messages from the tree control inside the COXSizeControlBar derived class. This happens even if AddPage from the Dundas tab control makes m_wndTree.SetParent(this) where 'this' is the tab control !!!!!!!! So in fact, I am handling messages inside the grandparent window class (The COXSizeControlBar. I have also a COXShortcutBar inside the tab control and for this I made the same thing than with the tree control. I passed a pointer to the COXSizeControlBar in the create method of the shortcut bar and then added it to a page of the tab control (COX3DTabViewBar). As you know, AddPage() sets to 'this' the parent window of control passed as argument of the AddPage() method. In this case, I was not able to process messages inside the COXSizeControlBar. I found out that it is because COXSizeControlBar 'only' sends messages to its parent/owner window so it is only possible to process them there. What is surprising to me is that I am able to process messages inside the grandparent window event if the Dundas code makes SetParent() to 'this' for the tree control inside the AddPage method of the tab control. I also tried to handle the messages inside a CTreeControl derived class and also it does not work. This means, I cannot handle messages inside a control's derived class which very annoying. I do not know if this is an MFC problem because I do not know what is going on. Any ideas of what is behind this behaviour? Best Regards, Miguel Re: Problems with message routing in COXSizeControlBar Ivor S. Sargoytchev2-Jun-03 11:25 Ivor S. Sargoytchev 2-Jun-03 11:25  Hi Miguel, The tree control (SysTreeView32) like all common controls sends the TVN_BEGINLABELEDIT notification thought WM_NOTIFY to its parent. The problem is that the parent to which the notification messages are sent is set at creation time (when ::CreateEx(...) for the tree is called) and cannot be changed later on. You can call SetParent(...) later on until you are blue in the face, but the messages will still be sent to the original parent. This is a problem with SysTreeView32 common control. You can easily reproduce it with a simple dialog based application where you have a tree control as a child of a tab control. The problem second problem - namely not being able to handle TVN_BEGINLABELEDIT in derived classes is a direct consequence of the problem that I just described. This is so because handling notification messages in derived classes relies on the parent window to reflect the message back to the child control. Ivor S. Sargoytchev Dundas Software Re: Problems with message routing in COXSizeControlBar Miguel Segarra4-Jun-03 1:07 Miguel Segarra 4-Jun-03 1:07  Thanks for the info and for solving my problem. I could not read it until today. Best Regards, Miguel how to add windows type properties to our own files..? harinath27-May-03 1:12 harinath 27-May-03 1:12  Hi, all In windows if we right click any file we get a popup menu which contains something like "undo, cut, copy....etc" My question is suppose I am doing a project where my file extention is .har. now When a user right clicks the .har files I want to add one extra menu item. Hope I gave clear idea about my question. Any help will be of good use to me thanks harinath Harinath Reddy HOneywell Technology Solutions Lab, Bangalore, India-560076 harinath@vandemataram.com Re: how to add windows type properties to our own files..? Rage27-May-03 1:21 Rage 27-May-03 1:21  As far as I know, that has to do with shell programming. Look at Mike Dunn's awesome articles about shell programming here on CP. A short explanation : Your file extension has an entry in the registry uder HKEY_CLASSES_ROOT\.har, and the associated value is your file names, like "Harinath Files". Then, under HKEY_CLASSES_ROOT\Harinath Files\shell\command\open, you have your application path, this meaning that the shell conmand "open" will launch the appliaction associated to .har files. Now if you add some other commands, then they will be showed in the menu. Check the articles I meant, and you'll see. ~RaGE(); Re: how to add windows type properties to our own files..? Rage27-May-03 1:23 Rage 27-May-03 1:23  That's the link http://www.codeproject.com/shell/shellextguideindex.asp[^] Spot part I and part III. ~RaGE(); Re: how to add windows type properties to our own files..? harinath27-May-03 1:29 harinath 27-May-03 1:29  Thank you buddy. I am reading the article. Thanks a lot. cheers harinath Harinath Reddy HOneywell Technology Solutions Lab, Bangalore, India-560076 harinath@vandemataram.com Re: how to add windows type properties to our own files..? harinath27-May-03 1:37 harinath 27-May-03 1:37  Thanks Harinath Reddy HOneywell Technology Solutions Lab, Bangalore, India-560076 harinath@vandemataram.com Problem by using Property Page as a Dialog praveenpnayak27-May-03 0:49 praveenpnayak 27-May-03 0:49  Hi, I am trying to use a property page as a dialog. When I bring up the property page using DoModal funtion, the controls in the property page do not get tabbed. TAB does not move the focus to the next control. Ex: CPropertyPage* pPage = new CPropertyPage(IDD_DIALOG1); pPage->DoModal(); If I use the same resource as a dialog, it works fine. I am able to tab to the next control in the dialog. Ex: CDialog* pDlg = new CDialog(IDD_DIALOG2); pDlg->DoModal(); Has anyone seen this behaviour before? Could I use property page as a dialog? Please let me know if you have any solutions for this. Thanks . Praveen Re: Problem by using Property Page as a Dialog Rage27-May-03 1:02 Rage 27-May-03 1:02  Why do you want to use a Property Page like that ? Create your property page, create one propertysheet, and Add() the propertypage to the property sheet. Then use pPropSheet->DoModal();, and here the dialog tabs are handled "normally". ~RaGE(); Re: Problem by using Property Page as a Dialog praveenpnayak27-May-03 1:27 praveenpnayak 27-May-03 1:27  I just wanted to reuse my code. I have the property page which I am adding it to the propertysheet in my app. I have commandline options for my app which will display only the property page as a dialog. Please let me know if you have any solution for this. Thanks . Praveen Re: Problem by using Property Page as a Dialog Rage27-May-03 2:33 Rage 27-May-03 2:33  I am not sure about that, but I actually think that this is because of the Wizard Mode ability of Propertypages. Generally, the tabs in PropertyPages are handled by their PropertySheet, and not by the Pages themselves. This allows the tabs in wizard mode to be set only on the back, next and finish buttons. Maybe you can try to mess with the m_psp member of the propertypage, maybe there actually is a way to set the tabs feature back, but I doubt it ... ~RaGE(); Re: Problem by using Property Page as a Dialog Renjith Ramachandran27-May-03 4:09 Renjith Ramachandran 27-May-03 4:09  You must insert the Properthpage in propertysheet Derive a Class from CPropertySheet says CMyProSheet oSheet; Derive a Class from CPropertypage says CMyProPage oPage1; in CMyProSheet Constructor, You just add the AddPage(&oPage1) Then oSheet.DoModal(); [ It is possible to represent everything in this universe by using 0 and 1 ] Re: Problem by using Property Page as a Dialog praveenpnayak28-May-03 0:11 praveenpnayak 28-May-03 0:11  Thanks guyz for helping. I have found a the solutions. The below code would solve my problem. BOOL MyPropPage::PreTranslateMessage(MSG* pMsg) { if( pMsg && (pMsg->message == WM_KEYDOWN)) { if (pMsg->wParam == VK_TAB) { CWnd* pNextControl = GetNextDlgTabItem(GetFocus(), (GetKeyState( VK_SHIFT ) & 0x8000)); if (pNextControl) GotoDlgCtrl(pNextControl);//pNextControl->SetFocus(); } } return CPropertyPage::PreTranslateMessage(pMsg); } Praveen DialogBox problem Jump_Around27-May-03 0:02 Jump_Around 27-May-03 0:02  I create DialogBox using Api Windows my question is how to get handle to this dialog before the dialog appears? in MFC i got CMyDlg dlg; now I am able to pass dlg somwhere (to the tread in my case) and I do dlg.doModal; I want to do similar thing in WinAPi but if I do DialogBox(hInst, MAKEINTRESOURCE(IDD_AUTHORIZATION), h, (DLGPROC)authDialog); the dialog box appears imiedetly, and I don't have HWND of it. Please help Re: DialogBox problem Daniel Strigl27-May-03 0:18 Daniel Strigl 27-May-03 0:18  It's not possible to work with the HWND of a dialog before the dialog is created! There exists no HWND until the dialog is created! If you want to use some functions that uses the HWND the dialog have to exist, otherwise the doesn't work! Daniel --------------------------- Never change a running system!

Last Visit: 31-Dec-99 18:00     Last Update: 24-Sep-24 19:20 Refresh ᐊ Prev1...14891148921489314894148951489614897148981489914900 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.