Do you have a Timer event running on another form in the database that'll steal focus? Even if this form's TimerInterval is 0, another open form with a Timer event that opens, activates, requeries, or refreshes something can sometimes grab the focus.

Also check whether any startup form, hidden form, AutoExec macro, or code running after the form opens is calling SetFocus, DoCmd.OpenForm, DoCmd.SelectObject, or similar. The fact that LostFocus isn't firing suggests the textbox may still technically have focus, but something is interfering with the caret display rather than actually moving focus.

I would also check, does your form re disable the disabled buttons when it opens or switches to another record? Access may.move the focus to those buttons or other controls if you have code for example in the on open, on load, or.on current event to make sure they are disabled at forst.

No other forms are open, this is literally the first form of the app.
No forms in the app have a timervalue other than 0.
No Macros, all VBA
If the box still had focus, typing would put text in the box ... yet it does not.
When a button is activated that opens another form the main form is closed, so On Load triggers ...


CAMin is the textbox in question

Sub RefreshMasterTable()
    Dim db As DAO.Database
    Dim tdf As DAO.TableDef
    Set db = CurrentDb
    Set tdf = db.TableDefs("Master")
    tdf.RefreshLink
    Set tdf = Nothing
    Set db = Nothing
End Sub

Private Sub Initialize_Form()
    Me.LowFireBtn.Enabled = False
    Me.HighFireBtn.Enabled = False
    Me.BuyBtn.Enabled = False
    Me.LoadKilnBtn.Visible = False
    Me.EmptyKilnBtn.Visible = False
    Me.WorkOrderStatusLabel.Visible = False
    Me.RejectBtn.Visible = False
    Me.WOStatus.Visible = False
    RefreshMasterTable
    Me.CAMin.SetFocus
End Sub

Private Sub Form_Load()
    Initialize_Form
End Sub

Jim  The only thing that seems out of the ordinary in your code is RefreshLink, which is usually used when you make changes to the tabledef itself (e.g. tdf.Connect = "C:\New\Path\...").  There is no change to the tabledef in your code, so I would think RefreshLink isn't needed.  Try removing it and see if the problem goes away.  It shouldn't make a textbox lose focus, so maybe something else is at play here.  Is the "Master" table the record source of the textbox?

Jim I tried putting similar code to yours in a database I test database I have and couldn't repeat the result myself. My next question might be are there any other programs, apps, or events running in Windows itself which may move focus away from Access? If you click on the form itself (i.e. reactivate the form), does focus return to the textbox in question for typing?

Kevin CAMin is an upbound textbox, the value is used to do a dlookup to determine which buttons to enable.  The table checked is Master, which is linked, and that's my way of ensuring I have the latest data ... I disabled it and it did not change the effect.

Donald Literally a new PC, nothing else running on it, but I'll validate that this morning. I get the same behavior on my dev machine ... which is ... different.   touching the form after it loses focus has no effect, touching the field activates it ... and then it never loses focus  ... but the cursor stops flashing ...and text can be entered.

Jim   A table doesn't need to be refreshed like a query or form does, since it always gives you the most up-to-date data when you reference it.  But as I said, RefreshLink doesn't and shouldn't unfocus a text box.  So I think the cause of the problem lies elsewhere in the database, maybe a corrupt object somewhere.  I've seen strange behavior -- so strange you wouldn't believe, not unlike this one -- from forms in many occasions due to corruption in the form and/or the controls.  Try re-creating the form, importing the form and other objects to a blank database, etc.

Kevin is right that RefreshLink isn't needed just to get current data from a normal linked Access table. When you run a query or DLookup against Master, Access reads the current data. The one situation where I routinely refresh linked tables at startup is with SQL Server or other remote online ODBC tables. I do that in my own applications to make sure the remote links are alive and their metadata is current.

Since removing RefreshLink didn't change anything, I don't think that's the culprit here.

The blinking caret by itself is not a reliable indication of focus. The fact that it eventually becomes solid but you can still type into CAMin suggests this may be a display/Windows caret issue rather than Access actually moving focus. On the other hand, if there are times when it really won't accept keystrokes, then something is definitely stealing keyboard focus.

I would add temporary diagnostic events to CAMin and the form so you can see exactly what Access thinks is happening:

Private Sub CAMin_GotFocus()
    Debug.Print "CAMin GotFocus"
End Sub

Private Sub CAMin_LostFocus()
    Debug.Print "CAMin LostFocus"
End Sub

Private Sub Form_Activate()
    Debug.Print "Form Activate"
End Sub

Private Sub Form_Deactivate()
    Debug.Print "Form Deactivate"
End Sub

Open the Immediate Window with Ctrl+G and watch it when the five-second behavior occurs. If CAMin_LostFocus never prints, then the control never actually lost focus and we're chasing a caret-display problem, not a focus problem.

Also, because it happens on both machines, I would look for anything else that runs during startup but isn't a form Timer event: a startup procedure, an AutoKeys macro, an add-in, a hidden startup object, or code in any application-level error handler. Search the whole project for SetFocus, Activate, OpenForm, SelectObject, RunCommand, Refresh, and Requery.

If the diagnostic events show no actual focus change, try creating a brand-new unbound test form with just one textbox and this in Form_Load:

Private Sub Form_Load()
    CAMin.SetFocus
End Sub

If that little test form behaves normally, then the original form may have some corruption or an odd property/control issue. In that case, rebuilding the form in a new object is often faster than trying to hunt down a gremlin hiding in the form definition.