CDialog derived Child
-
I have an SDI application with a FormView. The FormView has two buttons. One opens a CDialog derived class that is Modal and a Child. The other opens a CDialog derived class that is Modeless and a Child. Everything works fine when the Child style is removed and WS_POPUP is applied. When it is applied the dialogs open up but are (Modal and Child) behind Mainframe with no way to get at it except minimize Mainframe. After the minimization of Mainframe the dialog does not allow one to click on it (Frame titlebar is grayed. I believe the whole dialog box is disabled. (Modeless and Child appears but does not allow one to click on it as the Frame titlebar is grayed. I believe the whole dialog box is disabled. Now understand everything works as it should with the WS_POPUP style. Switch that and I get problems. The ONLY difference is the style. What is wrong? Thanks. //Modal Child void CParentExamplesView::OnButton3() { CModalChild cmd; cmd.DoModal(); } //Modeless Child void CParentExamplesView::OnButton4() { if (!m_pModelessChildDialog) m_pModelessChildDialog= new CModelessChild; if (!::IsWindow(m_pModelessChildDialog->GetSafeHwnd())) m_pModelessChildDialog->Create(IDD_DIALOG6, this); m_pModelessChildDialog->ShowWindow(SW_SHOW); }
-
I have an SDI application with a FormView. The FormView has two buttons. One opens a CDialog derived class that is Modal and a Child. The other opens a CDialog derived class that is Modeless and a Child. Everything works fine when the Child style is removed and WS_POPUP is applied. When it is applied the dialogs open up but are (Modal and Child) behind Mainframe with no way to get at it except minimize Mainframe. After the minimization of Mainframe the dialog does not allow one to click on it (Frame titlebar is grayed. I believe the whole dialog box is disabled. (Modeless and Child appears but does not allow one to click on it as the Frame titlebar is grayed. I believe the whole dialog box is disabled. Now understand everything works as it should with the WS_POPUP style. Switch that and I get problems. The ONLY difference is the style. What is wrong? Thanks. //Modal Child void CParentExamplesView::OnButton3() { CModalChild cmd; cmd.DoModal(); } //Modeless Child void CParentExamplesView::OnButton4() { if (!m_pModelessChildDialog) m_pModelessChildDialog= new CModelessChild; if (!::IsWindow(m_pModelessChildDialog->GetSafeHwnd())) m_pModelessChildDialog->Create(IDD_DIALOG6, this); m_pModelessChildDialog->ShowWindow(SW_SHOW); }
Dialogs SHOULD have parents! CModalChild cmd; cmd.DoModal(this); m_pModelessChildDialog= new CModelessChild(this); So give THAT a try.
-
Dialogs SHOULD have parents! CModalChild cmd; cmd.DoModal(this); m_pModelessChildDialog= new CModelessChild(this); So give THAT a try.
-
I have an SDI application with a FormView. The FormView has two buttons. One opens a CDialog derived class that is Modal and a Child. The other opens a CDialog derived class that is Modeless and a Child. Everything works fine when the Child style is removed and WS_POPUP is applied. When it is applied the dialogs open up but are (Modal and Child) behind Mainframe with no way to get at it except minimize Mainframe. After the minimization of Mainframe the dialog does not allow one to click on it (Frame titlebar is grayed. I believe the whole dialog box is disabled. (Modeless and Child appears but does not allow one to click on it as the Frame titlebar is grayed. I believe the whole dialog box is disabled. Now understand everything works as it should with the WS_POPUP style. Switch that and I get problems. The ONLY difference is the style. What is wrong? Thanks. //Modal Child void CParentExamplesView::OnButton3() { CModalChild cmd; cmd.DoModal(); } //Modeless Child void CParentExamplesView::OnButton4() { if (!m_pModelessChildDialog) m_pModelessChildDialog= new CModelessChild; if (!::IsWindow(m_pModelessChildDialog->GetSafeHwnd())) m_pModelessChildDialog->Create(IDD_DIALOG6, this); m_pModelessChildDialog->ShowWindow(SW_SHOW); }
mx483 wrote: Now understand everything works as it should with the WS_POPUP style. Switch that and I get problems. So why are you not wanting to use
WS_POPUP? You've not indicated that you would rather useWS_CHILD. All I can gather is that you've found something that works and want to know why.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
-
mx483 wrote: Now understand everything works as it should with the WS_POPUP style. Switch that and I get problems. So why are you not wanting to use
WS_POPUP? You've not indicated that you would rather useWS_CHILD. All I can gather is that you've found something that works and want to know why.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
Actually.. I found something that didn't work and wanted to know why. This is how I learn. I have no need to use the dialog as a child in modal or modeless...yet, but knowing why something does and doesn't work is paramount in continuing my growth as a programmer. I realize most people just solve a problem and blindly move on never really gaining from the experience. Solidifying concepts is what I'm trying to do. I really hoped people wouldn't constantly ask why I want to do this or that. My question was not a should or shouldn't but rather a why. I appreciate your taking the time to answer though.
-
Actually.. I found something that didn't work and wanted to know why. This is how I learn. I have no need to use the dialog as a child in modal or modeless...yet, but knowing why something does and doesn't work is paramount in continuing my growth as a programmer. I realize most people just solve a problem and blindly move on never really gaining from the experience. Solidifying concepts is what I'm trying to do. I really hoped people wouldn't constantly ask why I want to do this or that. My question was not a should or shouldn't but rather a why. I appreciate your taking the time to answer though.
Anonymous wrote: I found something that didn't work and wanted to know why. Really? When I read your post, it's easy to come away with a different impression. Consider, "I'm trying to drive a nail into a board with a hammer. Now understand everything works as it should with the nail. Switch that to a screw instead and I get problems. What is wrong?" Or, "I'm trying to drive my car with round tires. Now understand everything works as it should with the round tires. Switch that to out-of-round tires instead and I get problems. What is wrong?" See the confusion? Anonymous wrote: I really hoped people wouldn't constantly ask why I want to do this or that. My question was not a should or shouldn't but rather a why. While I certainly understand and applaud your situation, what I have found over the years is that when folks get stuck and ask for help, it is usually because they are doing something wrong (at the design level) that should never have been done to begin with. This is especially true with MFC. Most folks, especially new ones, have no idea what MFC is doing behind the scenes. They've learned it from the outside-in rather than from the inside-out. Knowing what the underlying Win32 SDK is actually doing is very important in making a successful application. Consequently they make erroneous assumptions (e.g., "But I thought message maps worked this way."), thus leading to a situation where they are trying to solve a problem that was doomed from the start. That said, MSDN clearly states: Do not use the WS_CHILD style with a modal dialog box. The DialogBox function always disables the parent/owner of the newly created dialog box. When a parent window is disabled, its child windows are implicitly disabled. Since the parent window of the child-style dialog box is disabled, the child-style dialog box is too.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
-
Anonymous wrote: I found something that didn't work and wanted to know why. Really? When I read your post, it's easy to come away with a different impression. Consider, "I'm trying to drive a nail into a board with a hammer. Now understand everything works as it should with the nail. Switch that to a screw instead and I get problems. What is wrong?" Or, "I'm trying to drive my car with round tires. Now understand everything works as it should with the round tires. Switch that to out-of-round tires instead and I get problems. What is wrong?" See the confusion? Anonymous wrote: I really hoped people wouldn't constantly ask why I want to do this or that. My question was not a should or shouldn't but rather a why. While I certainly understand and applaud your situation, what I have found over the years is that when folks get stuck and ask for help, it is usually because they are doing something wrong (at the design level) that should never have been done to begin with. This is especially true with MFC. Most folks, especially new ones, have no idea what MFC is doing behind the scenes. They've learned it from the outside-in rather than from the inside-out. Knowing what the underlying Win32 SDK is actually doing is very important in making a successful application. Consequently they make erroneous assumptions (e.g., "But I thought message maps worked this way."), thus leading to a situation where they are trying to solve a problem that was doomed from the start. That said, MSDN clearly states: Do not use the WS_CHILD style with a modal dialog box. The DialogBox function always disables the parent/owner of the newly created dialog box. When a parent window is disabled, its child windows are implicitly disabled. Since the parent window of the child-style dialog box is disabled, the child-style dialog box is too.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
And by stating the MSDN position you have answered the why! Thanks, that's all I wanted. Now I know not to do it and am richer for having asked. If I had known MSDN's position, which I was not able to locate in any of the help, I never would have asked in the first place. "One does not have to get burned to actually learn that fire is hot. Otherwise we would all be dead" mx483