Clicking a button and pressing Enter key act different in MDI clie

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

Bernie
Mon Jan 03 16:08:09 CST 2005

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

molly
Mon Jan 03 16:39:03 CST 2005

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
>
>
>

Bernie
Mon Jan 03 18:05:49 CST 2005

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

"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
>>
>>
>>

molly
Tue Jan 04 17:05:06 CST 2005

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:

> 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

v-jetan
Wed Jan 05 01:04:00 CST 2005

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.

molly
Wed Jan 05 21:27:02 CST 2005

Jeffrey,
Don't know if you saw the last post since I did it using Outlook Express.

"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-jetan@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

v-jetan
Thu Jan 06 02:45:11 CST 2005

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.

molly
Thu Jan 06 07:21:04 CST 2005

yes, my nospam email username is Molly but my ID is tsiGeorge. Go figure.

""Jeffrey Tan[MSFT]"" wrote:

> 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.
>
>

v-jetan
Fri Jan 07 01:42:45 CST 2005

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.

v-jetan
Mon Jan 10 01:07:20 CST 2005

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.

molly
Mon Jan 10 10:17:08 CST 2005

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.
>
>

v-schang
Tue Jan 11 03:34:15 CST 2005

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.)

v-jetan
Mon Jan 17 02:46:40 CST 2005

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.

v-jetan
Mon Jan 24 00:28:25 CST 2005

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.

molly
Sat Jan 29 13:31:01 CST 2005

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()
> > Form2.WindowState = FormWindowState.Maximized

If the first thing the MDI client does is to display a dialog window (e.g,.
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.

"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.
> >
> >

v-jetan
Mon Jan 31 00:03:52 CST 2005

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.

molly
Mon Jan 31 21:29:02 CST 2005

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:

> 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.
>
>

molly
Wed Feb 09 16:17:04 CST 2005

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:

> 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

v-jetan
Fri Feb 11 00:53:48 CST 2005

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.

v-jetan
Thu Feb 17 23:44:56 CST 2005

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.

v-jetan
Mon Feb 21 20:21:09 CST 2005

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.

molly
Mon Feb 21 20:51:03 CST 2005



""Jeffrey Tan[MSFT]"" wrote:

> 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.
>
>

molly
Mon Feb 21 21:23:09 CST 2005

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:

> 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.
>
>

molly
Thu Mar 03 23:09:05 CST 2005

Jeffrey,
Continuing at "MDI Client Problems"

""Jeffrey Tan[MSFT]"" wrote:

> 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