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

G

Guest

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

Bernie Yaeger

Hi George,

Do you have the form's acceptbutton set to a different button?

HTH,

Bernie Yaeger
 
G

Guest

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

Bernie Yaeger

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
 
G

Guest

Sorry, but I don't see the attachement and don't even see an attachement
option. I'm using the Web newsreader.
 
J

Jeffrey Tan[MSFT]

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

Guest

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

tsiGeorge said:
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]" said:
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
 
J

Jeffrey Tan[MSFT]

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

Jeffrey Tan[MSFT]

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

Jeffrey Tan[MSFT]

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="Jeffrey+Tan"+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.
 
G

Guest

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

Steven Cheng[MSFT]

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

Jeffrey Tan[MSFT]

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

Jeffrey Tan[MSFT]

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

Guest

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,.
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 said:
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]" said:
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="Jeffrey+Tan"+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.
 
J

Jeffrey Tan[MSFT]

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

Guest

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

Guest

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]" said:
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
 
J

Jeffrey Tan[MSFT]

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top