Keyboard accelerators don't work correctly in MDI application

  • Thread starter Thread starter Eric Guthmann
  • Start date Start date
E

Eric Guthmann

I'm having an unusual problem in an MDI application I'm working on. It
seems that when one MDI child is active, pressing keyboard accelerator keys
will sometimes activate buttons that are not on the active MDI child, but
rather on a non-active MDI child.

For example, if I have two MDI child forms open:

Form1
Button1: &View

Form2
TextBox1
Button2: &View
TextBox2

If Form2 is active and I'm in TextBox1, pressing Alt+V will click Button2.
If Form2 is active and I'm in TextBox2, pressing Alt+V will click Button1 on
the non-active Form1.

This seems like a serious bug in the .NET Framework 1.1. Has anyone else
seen this behavior? Is there a recommended workaround?

I also see a similar behavior when I'm using the TabControl:

Form3:
TabControl
TabPage1
Button1: &View

TabPage2
TextBox1
Button2: &View
TextBox2

If TabPage2 is active and I'm in TextBox1, pressing Alt+V will click
Button2.
If TabPage2 is active and I'm in TextBox2, pressing Alt+V will click Button1
on the non-active TabPage1.

It appears that the framework is searching for keyboard accelerators across
MDI forms and non-visible TabPage boundaries.

Any help is much appreciated!
 
Eric Guthmann said:
I'm having an unusual problem in an MDI application I'm working on. It
seems that when one MDI child is active, pressing keyboard accelerator keys
will sometimes activate buttons that are not on the active MDI child, but
rather on a non-active MDI child.
Click to expand...

I am sure there is a good reason for it, someone will probably chime in.

I have a wrapper around the button class (always a good thing!), and stuck
this in it:

Protected Overrides Function ProcessMnemonic(ByVal charCode As Char) As
Boolean

' ignore when MDI child form is not focused

If (Not Me.FindForm Is Nothing) AndAlso (Not DirectCast(Me.FindForm,
Form).MdiParent Is Nothing) AndAlso (Not DirectCast(Me.FindForm,
Form).MdiParent.ActiveMdiChild Is Me.FindForm) Then

Return False

End If

Return MyBase.ProcessMnemonic(charCode)

End Function




Best Regards,

Andy
 
Thanks for the reply Andy.

I did think about overriding controls, but the problem would be that I'd
have to wrap labels, buttons, groupboxes, and anything else that happened to
have a mnemonic.

What I have done so far is override handling of ProcessDialogKey in my MDI
container. That generally works, but I seem to be rewriting quite a bit of
code just locating keyboard accelerators in the correct tab order. Is there
a better workaround out there?
 
Eric Guthmann said:
What I have done so far is override handling of ProcessDialogKey in my MDI
container. That generally works, but I seem to be rewriting quite a bit of
code just locating keyboard accelerators in the correct tab order. Is there
a better workaround out there?
Click to expand...

I haven't seen one yet, but you can bet I'll be watching this thread to see
the input of others!

Best Regards,

Andy
 
Found one.

Create a base class that all of your MDI child forms inherit from instead of
System.Windows.Forms.Form. In the base class, override the
ProcessDialogChar method:

Protected Overrides Function ProcessDialogChar(ByVal charCode As Char) As
Boolean
If charCode <> " "c AndAlso ProcessMnemonic(charCode) Then
Return True
End If
Return False
End Function

Incidentally, Microsoft says this bug will be fixed in a future version and
is available as a hotfix now.
 
I should also add that this does not take care of the problem I'm seeing
with the TabControl where mnemonics on non-visible tab pages are selected,
but I suspect a similar workaround will take care of the problem.
 
Eric Guthmann said:
Found one.

Create a base class that all of your MDI child forms inherit from instead of
System.Windows.Forms.Form. In the base class, override the
ProcessDialogChar method:

Protected Overrides Function ProcessDialogChar(ByVal charCode As Char) As
Boolean
If charCode <> " "c AndAlso ProcessMnemonic(charCode) Then
Return True
End If
Return False
End Function

Incidentally, Microsoft says this bug will be fixed in a future version and
is available as a hotfix now.
Click to expand...

Excellent. The forms must see it before passing to the contained controls.
I can simplify my code now.

Thanks!

Best Regards,

Andy
 
Back
Top