I am calling me.setFocus from within the the lostFocus event of a combo box. Interesting result. The focus indeed shifts back to the comboBox but the cursor is absent until I click the control. When I try typing, despite the absent cursor, nothing appears until I click the form, anywhere will do, and then the characters that were typed make an appearance. The point of this is to accommodate data entry by a touch typist.
Is this a bug, am I misunderstanding, do I expect too much?
Anyone know of a workaround?
//ComboBox
Sub LostFocus() Handles LostFocus
// refresh existing customer record
If Data.dbIsNameKey(name) Then
RefreshCustomer
Return
End If
//customer name alias does not exist
Var dlg As New MessageDialog, result As MessageDialogButton
if NewCustomerDialog(name, dlg) = dlg.CancelButton Then
Me.SetFocus
Return
End If
//create new alias
End Sub
Probably related to the MessageDialog removing focus from the entire window. Even though focus eventually goes back to the window after the dialog is dismissed, not sure that has happened yet at this point in your code.
You could comment out the dialog part to verify whether it works (soon as you tab or click off it should go right back).
You might could also try using a fully qualified name (window + control) instead of Me for the SetFocus call. (the point being referencing the window directly may shift the focus immediately)
hmmmmm …
I’d thought the same as @jmadren that some how the message dialog was messing things up
But in a quick test I’m not seeing that here
I have a textfield and combobox on a layout in 202r2.1 on Catalina
Combobox1.lostfocus is the ONLY event implmeneted
//customer name alias does not exist
Var dlg As New MessageDialog
Var result As MessageDialogButton
dlg.CancelButton.Visible = True
result = dlg.ShowModal
If result = dlg.CancelButton Then
Me.SetFocus
Return
End If
if I run and tab into then out of the combobox
the combo loses focus
the msgdialog shows
if I press cancel focus returns to the combobox and I can type immediately
so something else may be responsible for what you’re seeing
What kind of control is the very first control in the tab order
A xojo control or one from a plugin ?
There was a bug where layouts with a control from a plugin couldn’t be first in the tab order
As far as I can remember, using SetFocus in the LostFocus event of a control doesn’t usually work. I’m surprised you’re getting a visual indication of focus, I would say the control doesn’t have focus if there’s no cursor and typing doesn’t do anything.
Try offloading the SetFocus from the LostFocus event stack using a Timer (0ms will do, it just needs to not be in the LostFocus event stack).
Thanks everyone. I took another look this morning.
I suspect the issue is something to do with this bit of input validation. Forgot it was there to be honest.
Function KeyDown(Key As String) Handles KeyDown as Boolean
Const validKeys As String = "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_#"
//accept control characters used to edit field
If (Asc(key) < 32) Or (Asc(key) = 127) Then
Return False
End If
Return (validKeys.IndexOf(key.Uppercase) < 0)
End Function
I say ‘suspect’ because yesterday I was in the office using Catalina and this morning I am at home using Monterey and can not reproduce the issue. I spent an hour on it yesterday so I’m definitely not imagining it.
I’m now wondering whether the odd behaviour is down to something in system preferences or a Catalina peculiarity. Anyhow the feature is not so important that I need to get bogged down by it. If it occurs in production they will just have to live with a mouse click.
Thanks again. I had forgotten how useful it can be to write your problem down and have others throw their oar in. [Without the pack descending to defend the indefensible by attacking the question.] Keep up the good work.