Overriding ProcessKeyPreview, Enter WM_KEYDOWN...

  • Thread starter Thread starter Ali Eghtebas
  • Start date Start date
A

Ali Eghtebas

Hi,

I have 3 questions regarding the code below:

1) Why can't I trap the KEYDOWN while I can trap KEYUP?
2) Is it correct that I use Return True within the IF-Statement? (I've
already read the documentation but it is rather hard to understand so please
don't refer to it :)
3) Many examples in the newsgroups use Return MyBase.ProcessKeyPreview(m) as
the last code line while I have used Return MyBase.ProcessKeyEventArgs(m)
according to the MSDN, is this correct or is it a typo in MSDN? (watch for
line breaks in the url)

ms-help://MS.VSCC/MS.MSDNVS/cpref/html/frlrfsystemwindowsformscontrolclasspr
ocesskeypreviewtopic.htm

I aslo wonder if my code is correct as to subtitude Enter key with Tab in a
specifik column of the a datagrid. It seems to function well when trapping
the WM_KEYUP but to get the desired effect I need
to trap the WM_KEYDOWN, and doesn't work!

Protected Overrides Function ProcessKeyPreview(ByRef m As
System.Windows.Forms.Message) As Boolean
Dim keyCode As Keys = CType(m.WParam.ToInt32, Keys) And Keys.KeyCode
Const WM_KEYDOWN As Integer = &H100
Const WM_KEYUP As Integer = &H101

If m.Msg = WM_KEYDOWN AndAlso keyCode = Keys.Enter _
AndAlso DataGridColumnStyle1.TextBox Is ActiveControl _
AndAlso DataGrid1.DataSource.GetType Is GetType(DataView) Then
SendKeys.Send("{Tab}")
Return True
End If
Return MyBase.ProcessKeyEventArgs(m)
End Function
 
1) Why can't I trap the KEYDOWN while I can trap KEYUP?
??? Whats happening when you try to trap keydown?
2) Is it correct that I use Return True within the IF-Statement? (I've
already read the documentation but it is rather hard to understand so please
don't refer to it :)
Click to expand...

The return value is dependant on what the function does. If you process the
key return true, if you don't, return false.
3) Many examples in the newsgroups use Return MyBase.ProcessKeyPreview(m) as
the last code line while I have used Return MyBase.ProcessKeyEventArgs(m)
according to the MSDN, is this correct or is it a typo in MSDN? (watch for
line breaks in the url)
Click to expand...

I can't see where ProcessKeyEventArgs appears anywhere, but it's wrong
anyway. It should be:

Return MyBase.ProcessKeyPreview(m)

This is because you are overriding the function, and so you are now letting
the original function process the key. The original function, that you
overrode, is not called, because you have overridden it, so calling that
line will call the original function and return the value that the original
function would have done.

(I hope that make sense)

Also, just FYI, Theres a better way to select the next control in a form,
other than sending the 'Tab' key (if you've seen my post about simulating
keystrokes earlier you'll realise I think it's bad). If you look at the
Me.SelectNextControl method, you can select the next control, based on the
ActiveControl:

Me.SelectNextControl(Me.ActiveControl, True)

More information on this:
<WatchForWrapping>
ms-help://MS.VSCC/MS.MSDNVS/cpref/html/frlrfsystemwindowsformscontrolclassse
lectnextcontroltopic.htm
</WatchForWrapping>

--
Happy to help,
-- Tom Spink
([email protected])

" There's no place like 127.0.0.1 "

Please respond to the newsgroup,
so all can benefit.


One Day,
 
The issue was solved by overriding ProcessCmdKey instead ;)
This might be an issue in .Net Framework 1.1.
 
Glad you've got it sorted!!

Technically this is correct, though I see why you might find it confusing.
It's all about how the new events in VB are delegate methods. It simply
means call the base class' version of the method to make sure it gets
notified of the message.

--
Happy to help,
-- Tom Spink
([email protected])

" There's no place like 127.0.0.1 "

Please respond to the newsgroup,
so all can benefit.


One Day,
Ali Eghtebas said:
The issue was solved by overriding ProcessCmdKey instead ;)
This might be an issue in .Net Framework 1.1.
--
Regards
Ali Eghtebas Sweden

Ali Eghtebas said:
Actually what happens is that nothing happens since the execution never gets
into the If-Statement where I want to replace the Enter key with Tab key.
NOTE that I use .Net Framework 1.1.
This must be a bug or something since according to the documentation I
should be able to trap both KEYDOWN and KEYUP, which seems to only apply on
KEYUP in this case.
To be more specifik m.Msg = WM_KEYUP returns True while m.Msg = WM_KEYDOWN
returns FALSE!
(watch
for


This makes sence to me and that is also what I thought but the only
confusing thing about it is MSDN:
"Notes to Inheritors: When overriding the ProcessKeyPreview method in a
derived class, a control should return true to indicate that it has
processed the key. For keys that are not processed by the control, the
result of calling the base class's ProcessKeyEventArgs method should be
returned."
Click to expand...
ms-help://MS.VSCC/MS.MSDNVS/cpref/html/frlrfsystemwindowsformscontrolclassse
The reason I want to replace the Enter Key with Tab is not that I want give
the focus to the next control on my form. I do this since in the last
Click to expand...
row
in
a DataGrid when editing a Cell the Enter Key doesn't assign the new
Click to expand...
value
to
the Cell since this is the last row and hence there is no next row to move
the focus on. I simply send Replace the Enter with Tab there to make the
change in the Cell and trigger other code within
CurrentCellChanged.
(watch
for
Click to expand...
ms-help://MS.VSCC/MS.MSDNVS/cpref/html/frlrfsystemwindowsformscontrolclasspr
Click to expand...
 
Back
Top