Don’t worry.
Please create an Issue with a sample project, you can say that this happens using Windows 11 but not macOS 13.6.3 (at least the quick sample I created using your code above).
maybe with the MessageBox this control raise a lost focus, which cause a KeyDown.
using the Keyboard status in this event looks odd.
in 2021r3.1 there was a Pressed Event if user ending the input by Enter or Lost Focus.
if focus changed the KeyDown get the tab key. (Win 10)
Function KeyDown(Key As String) Handles KeyDown as Boolean
System.DebugLog CurrentMethodName + " " + Str(Asc(Key))
Return True
End Function
Sub Pressed() Handles Pressed
System.DebugLog CurrentMethodName
End Sub
The problem lies in the first part of the code.
You need to tell the software to ignore the Enter; so Add Return True there.
Useing Return True means: do not pass the Key to the Event Loop. In your case, the MessageBox get it and the Event is another time fired…
New code:
If Keyboard.AsynckeyDown(&h24) or Keyboard.AsyncKeyDown(&h4c) Then
MessageBox("You pressed Enter")
Return True // Enter used…
Else
Return False
End If
No Xojo bug here.
More explanation [Here.](https://documentation.xojo.com/api/user_interface/desktop/desktopwindow.html#desktopwindow-keydown)
99% of the issues are already solved by events or other means in this case.
Perhaps the question should be what are you trying to achieve?
Is the text changed after enter? → use Pressed event
Is the text changed otherwise? → use TextChanged event.
Case closed, i mean why would one make things hard if there is no need to ?
The issue is presented to xojo by a feedback case.
The features shown can be resolved by other means already provided by Xojo.
You should avoid using MessageBox for displaying debugging messages. The displaying of the Message Box will alter event order and may give unexpected results. Instead use the Debugger, System.DebugLog or your own logging mechanism.
If I change the call to MessageBox() to use System.DebugLog() instead, then you see this:
1:43:20 PM : SearchFieldKeyDownIssue Launched
1:43:23 PM : Window1.SearchField1.KeyDown D
: You pressed Enter
So it appears that what is happening is that the MessageBox() is indeed causing the SearchField to lose focus, but for some reason this is generating a keydown event with CHR(9) which is ASCII TAB.
I am using the MessageBox to test / check to make sure that I was correctly capturing the Enter / Return keys.
Going forward I will follow the instructions you posted.
The flip side of this is that I do still believe the behavior to be incorrect.
Correct - I think that MessageBox() causing LostFocus() is expected behavior, and one of the main reasons to avoid using MessageBox() for debugging.
The bug as I see it, is this:
On Windows, Inside a SearchField.KeyDown Event, if the focus is lost during the event handler (such as by calling MessageBox()), a mysterious extra event of KeyDown(chr(9)) will be triggered.
Another issue:
the OP’s code does this:
If Keyboard.AsynckeyDown(&h24) or Keyboard.AsyncKeyDown(&h4c) Then
Since the keyDown event already includes the key as a parameter, this is a weird way to do it. It would be better to do this:
Event KeyDown(key as string) as boolean
if asc(key) = &h24 ...
This would also work around the bug since the “you pressed enter” condition would only happen once.
That doesn’t work for me. I’m learning this Keydown but looks like key is a string and asc converts to integer = 13 (return or enter for my extended keyboard with numeric keypad).
This works:
If Asc(key) = 13 Then
but doesn’t make a difference between Return and Enter, while Keyboard.AsynckeyDown(&h24) detects Return and Keyboard.AsyncKeyDown(&h4c) detects Enter. Maybe that doesn’t matter for OP but others may want to know if one key or the other is pressed.
Usually when I am typing, like right now, I will almost exclusively use the Return key. But sometimes, if numbers are involved I will use the Return key on numeric keypad and I expect Return and Enter to be functionally equivalent. Therefore, if I need to check for one I will check for the other as well.