|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Clicking a button and pressing Enter key act different in MDI clieIn our app (see: MDI Client problem - second try) clicking a button hides
(me.visible = false) the current client window and displays another client window (form.show the first time and then me.visible = true thereafter ). We have just noticed that if you tab to the button and press Enter the MdiChildActivate event does not fire and client is not displayed. Clicking always works. Anyone know what is wrong? Using Frameworks 1.1 with SP 1. -- tsiGeorge Hi George,
Do you have the form's acceptbutton set to a different button? HTH, Bernie Yaeger Show quoteHide quote "tsiGeorge" <molly@community.nospam> wrote in message news:3B318C31-8A07-410E-AABB-D0C2796036A1@microsoft.com... > In our app (see: MDI Client problem - second try) clicking a button hides > (me.visible = false) the current client window and displays another client > window (form.show the first time and then me.visible = true thereafter ). > We > have just noticed that if you tab to the button and press Enter the > MdiChildActivate event does not fire and client is not displayed. > Clicking > always works. Anyone know what is wrong? Using Frameworks 1.1 with SP 1. > -- > tsiGeorge No, the correct Click event fires and Me. visible = False is executed. The
question is why doesn't MdiChildActivate event fire. The Mdi Client is no longer active. Show quoteHide quote "Bernie Yaeger" wrote: > Hi George, > > Do you have the form's acceptbutton set to a different button? > > HTH, > > Bernie Yaeger > > "tsiGeorge" <molly@community.nospam> wrote in message > news:3B318C31-8A07-410E-AABB-D0C2796036A1@microsoft.com... > > In our app (see: MDI Client problem - second try) clicking a button hides > > (me.visible = false) the current client window and displays another client > > window (form.show the first time and then me.visible = true thereafter ). > > We > > have just noticed that if you tab to the button and press Enter the > > MdiChildActivate event does not fire and client is not displayed. > > Clicking > > always works. Anyone know what is wrong? Using Frameworks 1.1 with SP 1. > > -- > > tsiGeorge > > > Hi George,
Can we see the code inside the button's click event - when you tab to a button and press 'enter', its click event fires. Anything in there s/b executed at that point - it knows not what fired it. Bernie Show quoteHide quote "tsiGeorge" <molly@community.nospam> wrote in message news:DA713B39-A8A2-40B1-BCF1-A3107E3BD6C8@microsoft.com... > No, the correct Click event fires and Me. visible = False is executed. > The > question is why doesn't MdiChildActivate event fire. The Mdi Client is no > longer active. > > "Bernie Yaeger" wrote: > >> Hi George, >> >> Do you have the form's acceptbutton set to a different button? >> >> HTH, >> >> Bernie Yaeger >> >> "tsiGeorge" <molly@community.nospam> wrote in message >> news:3B318C31-8A07-410E-AABB-D0C2796036A1@microsoft.com... >> > In our app (see: MDI Client problem - second try) clicking a button >> > hides >> > (me.visible = false) the current client window and displays another >> > client >> > window (form.show the first time and then me.visible = true >> > thereafter ). >> > We >> > have just noticed that if you tab to the button and press Enter the >> > MdiChildActivate event does not fire and client is not displayed. >> > Clicking >> > always works. Anyone know what is wrong? Using Frameworks 1.1 with SP >> > 1. >> > -- >> > tsiGeorge >> >> >> Hi molly,
I have created a sample project for this issue, but it works well on my side. You may refer to the attachement in this reply for a test. I suggest you paste some code snippet or a sample project for us to reproduce out your issue. Then we can help you better. Thanks for your understanding. ======================== Thank you for your patience and cooperation. If you have any questions or concerns, please feel free to post it in the group. I am standing by to be of assistance. Best regards, Jeffrey Tan Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "as is" with no warranties and confers no rights. Sorry, but I don't see the attachement and don't even see an attachement
option. I'm using the Web newsreader. ""Jeffrey Tan[MSFT]"" wrote: Show quoteHide quote > Hi molly, > > I have created a sample project for this issue, but it works well on my > side. You may refer to the attachement in this reply for a test. > > I suggest you paste some code snippet or a sample project for us to > reproduce out your issue. Then we can help you better. Thanks for your > understanding. > ======================== > Thank you for your patience and cooperation. If you have any questions or > concerns, please feel free to post it in the group. I am standing by to be > of assistance. > > Best regards, > Jeffrey Tan > Microsoft Online Partner Support > Get Secure! - www.microsoft.com/security > This posting is provided "as is" with no warranties and confers no rights Hi molly,
The attachment can not be downloaded through Web newsreader, but you can get it through Outlook Express. You may type "msnews.microsoft.com" as the Outlook Express server address. Best regards, Jeffrey Tan Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "as is" with no warranties and confers no rights. I think you sample project is to simple. I've attached a VB project that
seems to demonstrate some of the problems I've been having. Form1 is the MDI parent and Form2 and Form3 are clients. Note that the tab order is different in Form2 and Form3. Form2 and Form3 both have WindowState = Maximized. Pressing the Switch button switches forms and the number in the text box is incremented. Here's what I see: 1) Form2 is displayed at maximum size the first time it is displayed. The focus is set to the text box and the back color is red to indicate that the Enter event fired. The text box is Tab 0. Also, since the value incremented we know that the Activated event fired. 2) Form3 is not displayed at maximum size the first time it is displayed. The text box back color is white to indicate the Enter event didn't fire. The text box is Tab 2. Value of text box is incremented by focus is wrong. 3) Click Select a number of times and you will notice that the WindowState of Form2 is no longer Maximized. Text box back color inidcates that the focus should be in the text box but it isn't 4)Next time Form3 is displayed press the Enter key. What happend to the client form? The closest I can get to a Maximized screen is to uncomment line 5 in Module1. Looking forward to your suggestions. Could this be a Microsoft bug? ""Jeffrey Tan[MSFT]"" <v-je***@online.microsoft.com> wrote in message Show quoteHide quote news:O4Zwjng8EHA.3512@cpmsftngxa10.phx.gbl... [attached file: Testapp.zip]> Hi molly, > > I have created a sample project for this issue, but it works well on my > side. You may refer to the attachement in this reply for a test. > > I suggest you paste some code snippet or a sample project for us to > reproduce out your issue. Then we can help you better. Thanks for your > understanding. > ======================== > Thank you for your patience and cooperation. If you have any questions or > concerns, please feel free to post it in the group. I am standing by to be > of assistance. > > Best regards, > Jeffrey Tan > Microsoft Online Partner Support > Get Secure! - www.microsoft.com/security > This posting is provided "as is" with no warranties and confers no rights. Jeffrey,
Don't know if you saw the last post since I did it using Outlook Express. Show quoteHide quote "tsiGeorge" wrote: > I think you sample project is to simple. I've attached a VB project that > seems to demonstrate some of the problems I've been having. Form1 is the MDI > parent and Form2 and Form3 are clients. Note that the tab order is different > in Form2 and Form3. Form2 and Form3 both have WindowState = Maximized. > Pressing the Switch button switches forms and the number in the text box is > incremented. > Here's what I see: > 1) Form2 is displayed at maximum size the first time it is displayed. The > focus is set to the text box and the back color is red to indicate that the > Enter event fired. The text box is Tab 0. Also, since the value incremented > we know that the Activated event fired. > 2) Form3 is not displayed at maximum size the first time it is displayed. > The text box back color is white to indicate the Enter event didn't fire. > The text box is Tab 2. Value of text box is incremented by focus is wrong. > 3) Click Select a number of times and you will notice that the WindowState > of Form2 is no longer Maximized. Text box back color inidcates that the > focus should be in the text box but it isn't > 4)Next time Form3 is displayed press the Enter key. What happend to the > client form? > > The closest I can get to a Maximized screen is to uncomment line 5 in > Module1. > Looking forward to your suggestions. Could this be a Microsoft bug? > > ""Jeffrey Tan[MSFT]"" <v-je***@online.microsoft.com> wrote in message > news:O4Zwjng8EHA.3512@cpmsftngxa10.phx.gbl... > > Hi molly, > > > > I have created a sample project for this issue, but it works well on my > > side. You may refer to the attachement in this reply for a test. > > > > I suggest you paste some code snippet or a sample project for us to > > reproduce out your issue. Then we can help you better. Thanks for your > > understanding. > > ======================== > > Thank you for your patience and cooperation. If you have any questions or > > concerns, please feel free to post it in the group. I am standing by to be > > of assistance. > > > > Best regards, > > Jeffrey Tan > > Microsoft Online Partner Support > > Get Secure! - www.microsoft.com/security > > This posting is provided "as is" with no warranties and confers no rights Hi molly,
Oh, sorry, but are "tsiGeorge" and you the same person? I just suspect that you are 2 different persons. Also, is your problem the same with the attachment project in "tsiGeorge"'s reply? Anyway, I will take some and look into the attached project and reply to you some time ASAP. Thanks for your understanding. Best regards, Jeffrey Tan Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "as is" with no warranties and confers no rights. yes, my nospam email username is Molly but my ID is tsiGeorge. Go figure.
""Jeffrey Tan[MSFT]"" wrote: Show quoteHide quote > Hi molly, > > Oh, sorry, but are "tsiGeorge" and you the same person? I just suspect that > you are 2 different persons. > > Also, is your problem the same with the attachment project in "tsiGeorge"'s > reply? > > Anyway, I will take some and look into the attached project and reply to > you some time ASAP. Thanks for your understanding. > > Best regards, > Jeffrey Tan > Microsoft Online Partner Support > Get Secure! - www.microsoft.com/security > This posting is provided "as is" with no warranties and confers no rights. > > Hi molly,
Sorry for letting you wait for so long. I have doing some research into your project and reproduced out your issue. If you view Form.MdiChildActivate Event in MSDN, you will see that: This event "Occurs when a multiple document interface (MDI) child form is activated or closed within an MDI application." But in your project, it seems that you use Form.Visible=false to invoke container's MdiChildActivate event. Based on the MSDN document above, this behavior is not mentioned, I think this is a undocumented behavior. Although, it works most of the time in Form.Visible=false, this behavior is not guaranteed. Actually, for your request, I think a more suggested design is swiching the child form visibility in Button click event, not in MdiChildActivate event. Also, I think this is not a hard task. Hope this reply makes sense to you. If you have any questions or concerns, please feel free to post it in the group. I am standing by to be of assistance. Best regards, Jeffrey Tan Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "as is" with no warranties and confers no rights. Hi,
I've revised the test app based on your input and it works slighty better. However, there are still some problems. I've made the following changes: 1)Removed the Form.MdiChildActivate Event 2)Added a Form.MyShow in the child forms 3)Anchor the buttons on Form3 to the left & bottom and the buttons on Form2 to left and top. 4)Set the form's WindowState to FormWindowState.Maximized before calling Form.MyShow. 5)Set MinimizeBox and MaximizeBox on Form2 to False The problems I still see are: 1)The buttons on Form3 are half off the screen. If you click Restore Down and then Maximize the buttons show properly until Form3 is redisplayed again. The buttons on Form2 show okay. 2)The Minimize and Restore Down/Maximize boxes on Form2 are still displayed. If you click Restore Down they disappear until the Form is redisplayed. 3)If you press Enter the Forms switch even though the focus is in the text box. Sometimes, the backcolor and cursor position is not correct and when that happens pressing Enter doesn't switch Forms (the correct operation). 4)When the back color is wrong it is either white with the insert point at the beginning of the text box or only the number has a back color and the insert point is after the number. Jeffrey, everything I've seen indicates that there is a bug that is caused by a race condition. Looking forward to your response Jeffrey Tan[MSFT] wrote: Show quoteHide quote > Hi molly, > > Sorry for letting you wait for so long. > > I have doing some research into your project and reproduced out your issue. > > If you view Form.MdiChildActivate Event in MSDN, you will see that: > This event "Occurs when a multiple document interface (MDI) child form is > activated or closed within an MDI application." > > But in your project, it seems that you use Form.Visible=false to invoke > container's MdiChildActivate event. Based on the MSDN document above, this > behavior is not mentioned, I think this is a undocumented behavior. > Although, it works most of the time in Form.Visible=false, this behavior is > not guaranteed. > > Actually, for your request, I think a more suggested design is swiching the > child form visibility in Button click event, not in MdiChildActivate event. > Also, I think this is not a hard task. > > Hope this reply makes sense to you. If you have any questions or concerns, > please feel free to post it in the group. I am standing by to be of > assistance. > > Best regards, > Jeffrey Tan > Microsoft Online Partner Support > Get Secure! - www.microsoft.com/security > This posting is provided "as is" with no warranties and confers no rights. > Hi tsigeorge,
Thanks very much for your feedback!! I have tried your sample project and reproduced out most of your issues. For #2, this is a known issue of Winform MDI, currently, you may follow the following workaround for this issue: http://groups.google.com/groups?q=%22Jeffrey+Tan%22+MDI+maximize&hl=zh-TW&lr =&selm=43PFbo%235EHA.3696%40cpmsftngxa10.phx.gbl&rnum=2 For #1, actuallly, this issue is caused by the in-correct setting for MDI Child form height when initialized displayed. If you print out the MDI child's height value at run-time 2 times: before clicking "Restore Down and then Maximize" and after clicking "Restore Down and then Maximize", with the following code: MessageBox.Show(Me.Height.ToString()) You will get 2 different height values. I am not sure if this is a bug of Winform MDI. But I think the workaround is simple, just exchange these 2 statements position: Form2.WindowState = FormWindowState.Maximized Form2.MyShow() to Form2.MyShow() Form2.WindowState = FormWindowState.Maximized For the rest issues, I will spend some more time into it and reply to you ASAP. Thanks for your understanding. ============================================== Thank you for your patience and cooperation. If you have any questions or concerns, please feel free to post it in the group. I am standing by to be of assistance. Best regards, Jeffrey Tan Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "as is" with no warranties and confers no rights. Jeffrey,
"No cigars." #2. I reviewed you google link. There are at least 3 problems with seting up the client this way. 1) A flicker. The client is displayed at a smaller size first and then changed to fill the parent's client space. 2) The height of the client is calculated wrong and the buttons are now about 60 pixels higher. 3) The client's title is not shown on the parent title bar (I guess because of the FormBorderStyle.None). If you don't see the flicker add more controls to client. It is very obvious in the production app. I guess I'm not the only one having problems with MdiClient's #1 Ah, buttons are displayed but you can see the client changing size which is very annoying. I don't think this will get through QA. I have the following controls set as: controlbox=true, formbodystyle=sizable, maximizebox=true, minimizebox=false. If you change controlbox=false and formbodystyle=none you get very weird results. It seems to be that this is a bug caused by the client height not being calculated correctly prior to the show. Any other thoughts on this and other problems? ""Jeffrey Tan[MSFT]"" wrote: Show quoteHide quote > Hi tsigeorge, > > Thanks very much for your feedback!! > > I have tried your sample project and reproduced out most of your issues. > > For #2, this is a known issue of Winform MDI, currently, you may follow the > following workaround for this issue: > http://groups.google.com/groups?q=%22Jeffrey+Tan%22+MDI+maximize&hl=zh-TW&lr > =&selm=43PFbo%235EHA.3696%40cpmsftngxa10.phx.gbl&rnum=2 > > For #1, actuallly, this issue is caused by the in-correct setting for MDI > Child form height when initialized displayed. If you print out the MDI > child's height value at run-time 2 times: before clicking "Restore Down and > then Maximize" and after clicking "Restore Down and then Maximize", with > the following code: > MessageBox.Show(Me.Height.ToString()) > You will get 2 different height values. > > I am not sure if this is a bug of Winform MDI. But I think the workaround > is simple, just exchange these 2 statements position: > Form2.WindowState = FormWindowState.Maximized > Form2.MyShow() > to > Form2.MyShow() > Form2.WindowState = FormWindowState.Maximized > > For the rest issues, I will spend some more time into it and reply to you > ASAP. Thanks for your understanding. > ============================================== > Thank you for your patience and cooperation. If you have any questions or > concerns, please feel free to post it in the group. I am standing by to be > of assistance. > > Best regards, > Jeffrey Tan > Microsoft Online Partner Support > Get Secure! - www.microsoft.com/security > This posting is provided "as is" with no warranties and confers no rights. > > Hi tsigeorge,
Thanks for your response. Regarding on this issue, we're currently doing some further research and will update you as soon as possible. Thanks for your understanding. Regards, Steven Cheng Microsoft Online Support Get Secure! www.microsoft.com/security (This posting is provided "AS IS", with no warranties, and confers no rights.) Hi
Sorry for letting you wait for so long. For #1, #2, we are still doing research on it. Issue#3: This is by design. The focus is actually in the button and not in the text box. This happens because the text box cannot get the focus at that point because the MDI parent is not yet visible, that call need to be moved to MdiParentForm.Activated. Issue#4: We still can not reproduce. I suggest you provide more detailed repro steps. =============================================== Thank you for your patience and cooperation. If you have any questions or concerns, please feel free to post it in the group. I am standing by to be of assistance. Best regards, Jeffrey Tan Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "as is" with no warranties and confers no rights. Hi,
Sorry for the delay reponse. We have done a lot of research in this issue and find that for #2, this behavior is by design, there is a Access2000 MDI issue the same as this one: "ACC2000: Maximized Form Shows Control Box and Minimize, Maximize, and Restore Buttons" http://support.microsoft.com/?id=210299 In this issue you can see the statement that "The default behavior for an MDI application is for all maximized child windows to display a Control menu box and a Restore button. " And there is already a workaround in this KB, we may just P/invoke some Win32 APIs to workaround this issue. Also, this workaround gets rid of the #1 problem. Hope this helps. Thank you for your patience and cooperation. If you have any questions or concerns, please feel free to post it in the group. I am standing by to be of assistance. Best regards, Jeffrey Tan Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "as is" with no warranties and confers no rights. Jeffrey,
Haven't heard from you for 2 weeks and I'm still waiting for a workable solution. I've run into some more problems with: > Form2.MyShow() If the first thing the MDI client does is to display a dialog window (e.g,. > > Form2.WindowState = FormWindowState.Maximized Save File) then the client is shown at normal size. Between the flickering and this problem there is no way QA is going to accept this. Any other ideas? Looking forward to a quick answer to this and the other problems. Thanks. Show quoteHide quote "tsiGeorge" wrote: > Jeffrey, > "No cigars." > #2. I reviewed you google link. There are at least 3 problems with seting up > the client this way. 1) A flicker. The client is displayed at a smaller size > first and then changed to fill the parent's client space. 2) The height of > the client is calculated wrong and the buttons are now about 60 pixels > higher. 3) The client's title is not shown on the parent title bar (I guess > because of the FormBorderStyle.None). If you don't see the flicker add more > controls to client. It is very obvious in the production app. I guess I'm not > the only one having problems with MdiClient's > > #1 Ah, buttons are displayed but you can see the client changing size which > is very annoying. I don't think this will get through QA. I have the > following controls set as: > controlbox=true, formbodystyle=sizable, maximizebox=true, minimizebox=false. > > If you change controlbox=false and formbodystyle=none you get very weird > results. > > It seems to be that this is a bug caused by the client height not being > calculated correctly prior to the show. Any other thoughts on this and other > problems? > > ""Jeffrey Tan[MSFT]"" wrote: > > > Hi tsigeorge, > > > > Thanks very much for your feedback!! > > > > I have tried your sample project and reproduced out most of your issues. > > > > For #2, this is a known issue of Winform MDI, currently, you may follow the > > following workaround for this issue: > > http://groups.google.com/groups?q=%22Jeffrey+Tan%22+MDI+maximize&hl=zh-TW&lr > > =&selm=43PFbo%235EHA.3696%40cpmsftngxa10.phx.gbl&rnum=2 > > > > For #1, actuallly, this issue is caused by the in-correct setting for MDI > > Child form height when initialized displayed. If you print out the MDI > > child's height value at run-time 2 times: before clicking "Restore Down and > > then Maximize" and after clicking "Restore Down and then Maximize", with > > the following code: > > MessageBox.Show(Me.Height.ToString()) > > You will get 2 different height values. > > > > I am not sure if this is a bug of Winform MDI. But I think the workaround > > is simple, just exchange these 2 statements position: > > Form2.WindowState = FormWindowState.Maximized > > Form2.MyShow() > > to > > Form2.MyShow() > > Form2.WindowState = FormWindowState.Maximized > > > > For the rest issues, I will spend some more time into it and reply to you > > ASAP. Thanks for your understanding. > > ============================================== > > Thank you for your patience and cooperation. If you have any questions or > > concerns, please feel free to post it in the group. I am standing by to be > > of assistance. > > > > Best regards, > > Jeffrey Tan > > Microsoft Online Partner Support > > Get Secure! - www.microsoft.com/security > > This posting is provided "as is" with no warranties and confers no rights. > > > > Hi tsigeorge,
Thanks for your feedback! Actually, I have added 2 replies to you in this thread several days before, but I think maybe you did not get my response. I will paste them here: We have done a lot of research in this issue and find that for #2, this behavior is by design, there is a Access2000 MDI issue the same as this one: "ACC2000: Maximized Form Shows Control Box and Minimize, Maximize, and Restore Buttons" http://support.microsoft.com/?id=210299 In this issue you can see the statement that "The default behavior for an MDI application is for all maximized child windows to display a Control menu box and a Restore button. ", Actually I have created a sample Win32 sample application, and we can also reproduce out this issue in Win32 environment. And there is already a workaround in this KB, we may just P/invoke some Win32 APIs to workaround this issue. Also, this workaround gets rid of the #1 problem. Issue#3: This is by design. The focus is actually in the button and not in the text box. This happens because the text box cannot get the focus at that point because the MDI parent is not yet visible, that call need to be moved to MdiParentForm.Activated. Issue#4: We still can not reproduce. I suggest you provide more detailed repro steps. ========================================================= Thank you for your patience and cooperation. If you have any questions or concerns, please feel free to post it in the group. I am standing by to be of assistance. Best regards, Jeffrey Tan Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "as is" with no warranties and confers no rights. Jeffrey
Checked out the KB article and since this was written for Access and not ..Net I am having problems converting the form.handle to hWnd. I've looked around for a method to convert the handle but haven't found anything. But, does this do anything more than : frmCompany1.Dock = DockStyle.Fill Does it remove the flicker? From the article: "You can use the following technique to simulate maximizing a window by sizing it as large as possible in the restored, windowed (non-maximized), state. " So this doesn't create a true maximized client. Also, this code looks very strange: MoveWindow F.hWnd, 0, 0, MDIRect.x2 - MDIRect.x1 + 4, _ MDIRect.y2 - MDIRect.y1 + 4, True What does the "+4" do? Does it change if XP Style is used? Right now I'm back to using the DockStyle.Fill since it has less flicker. Still seeing the client at normal size when the first thing that happens is a dialog window is displayed. ""Jeffrey Tan[MSFT]"" wrote: Show quoteHide quote > Hi tsigeorge, > > Thanks for your feedback! > > Actually, I have added 2 replies to you in this thread several days before, > but I think maybe you did not get my response. I will paste them here: > > We have done a lot of research in this issue and find that for #2, this > behavior is by design, there is a Access2000 MDI issue the same as this one: > "ACC2000: Maximized Form Shows Control Box and Minimize, Maximize, and > Restore Buttons" > http://support.microsoft.com/?id=210299 > > In this issue you can see the statement that "The default behavior for an > MDI application is for all maximized child windows to display a Control > menu box and a Restore button. ", Actually I have created a sample Win32 > sample application, and we can also reproduce out this issue in Win32 > environment. > > And there is already a workaround in this KB, we may just P/invoke some > Win32 APIs to workaround this issue. Also, this workaround gets rid of the > #1 problem. > > Issue#3: This is by design. The focus is actually in the button and not in > the text box. This happens because the text box cannot get the focus at > that point because the MDI parent is not yet visible, that call need to be > moved to MdiParentForm.Activated. > Issue#4: We still can not reproduce. I suggest you provide more detailed > repro steps. > ========================================================= > Thank you for your patience and cooperation. If you have any questions or > concerns, please feel free to post it in the group. I am standing by to be > of assistance. > > Best regards, > Jeffrey Tan > Microsoft Online Partner Support > Get Secure! - www.microsoft.com/security > This posting is provided "as is" with no warranties and confers no rights. > > Hi molly,
Sorry for letting you wait for so long. Yes, it seems that this is also not a suitable workaround for this issue. I have contacted our product team. As their feedback, this behavior should by design, because in Win32 code, the MDI Child also can not have a mdi child without maximize and minimize box. Currently, we can not find a perfect solution or workaround for this issue, and my original workaround of using non-caption bar form and Dock.Fill style should be the only avaible one, althrough with some flicker issue. Also, as we tested, if we swith between these 2 forms, the Form3 will not position well on the MDI client window, and 2 scrollbars will appear on the client area. I think we should re-position the Form3 to the correct position to fix this issue. Like this: Public Sub MyShow() Me.Show() Me.Left = 0 Me.Top = 0 End Sub I will attached the modified project in this reply. For your information. =========================================================== Thank you for your patience and cooperation. If you have any questions or concerns, please feel free to post it in the group. I am standing by to be of assistance. Best regards, Jeffrey Tan Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "as is" with no warranties and confers no rights. Jeffrey,
I spent some more time on this and the more time I spend the more confused I get. First, i'm not sure what this statement means: " I have contacted our product team. As their feedback, this behavior should by design, because in Win32 code, the MDI Child also can not have a mdi child without maximize and minimize box. " In the app the MDI child doesn't have a child. Only the parent MDI has children. Also, using the app us have I still get strange results. I've set the tabs so that the text box is 0, switch button is 1 and ext buttone is 2. Start the program and press Enter, Nothing happens (which is good) so I click Switch. Repeat on the next form. Also works corrently. Now first form is displayed again with value 2 in the text box. You can type in the box so we know the focus is in the text box. Press Enter and it swiches forms. What! Why did the button2_click fire? Repeat on next form. Text box has red background. Same thing happens. If you continue doing this you find that the form doesn't switch when the text background is white but always switches when it is red or blue. IT SHOULD NEVER SWITCH SINCE THERE IS NO ACCEPT BUTTON AND THE FOCUS IS IN THE TEXT BOX FIELD. If in the real app, I set the FormBorderStyle to None I get even stranger results. Sometimes no child is displayed and I end up with an empty MDI form. If the FormBorderStyle is Sizable then the app works correctly. Also, in the real app there seems to be no need to set me.top = 0 and me.left = 0 but in the test it is needed. Oh, I've also added two labels on the screen that show the width and height of the form and a message box in the switch box that is displayed if the current width/height is not the same as in the two labels. The label text is set in the Activated Sub. Why does the height change.? here is the code: Activated Sub Label1.Text = "Width = " & Me.Width Label2.Text = "Height = " & Me.Height button2 click Dim w As String = "Width = " & Me.Width Dim h As String = "Height = " & Me.Height If w <> Label1.Text Or h <> Label2.Text Then MessageBox.Show("Width/Height now " & w & ", " & h) End If I can't see how any of these actions can be "by design". They are not even consistant from form to form and click to click. George ""Jeffrey Tan[MSFT]"" wrote: Show quoteHide quote > Hi molly, > > Sorry for letting you wait for so long. > > Yes, it seems that this is also not a suitable workaround for this issue. > > I have contacted our product team. As their feedback, this behavior should > by design, because in Win32 code, the MDI Child also can not have a mdi > child without maximize and minimize box. > > Currently, we can not find a perfect solution or workaround for this issue, > and my original workaround of using non-caption bar form and Dock.Fill > style should be the only avaible one, althrough with some flicker issue. > > Also, as we tested, if we swith between these 2 forms, the Form3 will not > position well on the MDI client window, and 2 scrollbars will appear on the > client area. I think we should re-position the Form3 to the correct > position to fix this issue. Like this: > Public Sub MyShow() > Me.Show() > Me.Left = 0 > Me.Top = 0 > End Sub > > I will attached the modified project in this reply. For your information. > =========================================================== > Thank you for your patience and cooperation. If you have any questions or > concerns, please feel free to post it in the group. I am standing by to be > of assistance. > > Best regards, > Jeffrey Tan > Microsoft Online Partner Support > Get Secure! - www.microsoft.com/security > This posting is provided "as is" with no warranties and confers no rights Hi George,
Thanks for your feedback and sorry for the typo in my reply. The correct statement should be: "I have contacted our product team. As their feedback, this behavior should by design, because in Win32 code, the MDI application also can not have a mdi child without maximize and minimize box". So I just mean that MDI child form can not have a caption bar without maximize and minimizebox. For the later description, I think you should refer to #3 and #4 issue, yes? I will spend some time into this issue. Thanks ============================================= Thank you for your patience and cooperation. If you have any questions or concerns, please feel free to post it in the group. I am standing by to be of assistance. Best regards, Jeffrey Tan Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "as is" with no warranties and confers no rights. Hi George,
Sorry for letting you wait for so long. For these days, I have contacted the product team for #3 issue, then the product team has confirmed this issue as a bug. Below is the workaround: Create a new form to inherits the Form class and overrides its UpdateDefaultButton function. The code is: Public Class MyForm Inherits System.Windows.Forms.Form Protected Overrides Sub UpdateDefaultButton() ' Do nothing. End Sub End Class In the MDI form, inherits the Form from our inherited form instead of the original form class. Public Class Form1 Inherits MyForm Hope this helps. =========================================== Thank you for your patience and cooperation. If you have any questions or concerns, please feel free to post it in the group. I am standing by to be of assistance. Best regards, Jeffrey Tan Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "as is" with no warranties and confers no rights. Hi George,
Have you viewed my lastest reply? Does that workaround make sense to you? Please feel free to tell me, thanks. Best regards, Jeffrey Tan Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "as is" with no warranties and confers no rights. ""Jeffrey Tan[MSFT]"" wrote:
Show quoteHide quote > Hi George, > > Have you viewed my lastest reply? Does that workaround make sense to you? > Please feel free to tell me, thanks. > > Best regards, > Jeffrey Tan > Microsoft Online Partner Support > Get Secure! - www.microsoft.com/security > This posting is provided "as is" with no warranties and confers no rights. > > Hi Jeffrey,
YES! I got to try it yesterday. Don't understand why all I have to do is put the code in the base form. Thought I would have to put it in every form. I've come up with a workaround for the forms not filling the client area and sometimes not positioning correctly. I've changed the FormBorderStyle to None (this didn't work before your last workaround) and added a timer to the Activated Sub. It seems that anytime the Activated Sub took a long time because of processing or and Open/Save dialog the window didn't fill correctly. In our App we could end up requesting a file or doing thousands of database lookups (in our test we do 100,000). Right now the timer interval is 1 second and we do our processing in the TimerEventProcessor Sub. We also found that if you: 1. Show form2 2. Switch to form3 on a button click 3. Show form3 4. Switch back to form2 on a button click 5. Show form2 6. Switch back to form3 by program control 7. Show form3 The form that gets displayed is form2 and not form3. We fixed this by skipping #5. Don't understand why but anything that works can't be bad. Other comments: With the client filling properly the flicker is not as noticeable. Also, we picked up 1/2 to 3/4 inch of vertical space that we really needed in some forms. Will any of these problems be fixed? Will a KB article be written so the next victim will not have to spend 50 to 100 hours figuring this out. I'm not sure we resolved everthing. I need to read back through all the threads. Our App looks a lot better and we shipped two CD's today to key customers for them to try. Thanks George ""Jeffrey Tan[MSFT]"" wrote: Show quoteHide quote > Hi George, > > Have you viewed my lastest reply? Does that workaround make sense to you? > Please feel free to tell me, thanks. > > Best regards, > Jeffrey Tan > Microsoft Online Partner Support > Get Secure! - www.microsoft.com/security > This posting is provided "as is" with no warranties and confers no rights. > > Hi George,
Thanks for your feedback!! I think we only need to add the workaround code snippet in the base form, please refer to the sample project in this reply. Also, for your other statement, I am not sure I understand your problem, where does your timer come from? is this a new problem? Or have you ever mention this issue in the original post? I hope you explain this issue in more details. Thanks Also, I think this thread is too long, I suggest you paste a new post, then we may continue the following issue. ======================================================== Thank you for your patience and cooperation. If you have any questions or concerns, please feel free to post it in the group. I am standing by to be of assistance. Best regards, Jeffrey Tan Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "as is" with no warranties and confers no rights. Jeffrey,
Continuing at "MDI Client Problems" ""Jeffrey Tan[MSFT]"" wrote: Show quoteHide quote > Hi George, > > Thanks for your feedback!! > > I think we only need to add the workaround code snippet in the base form, > please refer to the sample project in this reply. > > Also, for your other statement, I am not sure I understand your problem, > where does your timer come from? is this a new problem? Or have you ever > mention this issue in the original post? I hope you explain this issue in > more details. Thanks > > Also, I think this thread is too long, I suggest you paste a new post, then > we may continue the following issue. > ======================================================== > Thank you for your patience and cooperation. If you have any questions or > concerns, please feel free to post it in the group. I am standing by to be > of assistance. > > Best regards, > Jeffrey Tan > Microsoft Online Partner Support > Get Secure! - www.microsoft.com/security > This posting is provided "as is" with no warranties and confers no rights  
Other interesting topics
Adding/Updating assemblies in GAC during runtime and not during Se
OT: Replacement for Adobe Acrobat Drag Drop Data pictures to my Form Label with Transparent Background Inheritance in forms which inherit template forms MessageBox and Focus New Thread MessageBox and Form load Obtain default curtom control size Outlook Style Calendar Control |
|||||||||||||||||||||||
