The Problem (Q-score 5, ranked #20th of 67 in the Access VBA archive)
The scenario as originally posted in 2013
I am creating a personal Library Inventory system using an Access 2007 database. In code, whenever I reference the .Text property of a form control, whether it be changing the value, or simply checking the value in an IF statement, I get prompted with Run-time error '2185': You can't reference a property or method for a control unless the control has the focus.
Why is this?
For setting the .Text it’s not a huge deal, but when I’m checking the value in an IF statement, I can’t set the focus when I’m checking multiple conditions.
Why community consensus is tight on this one
Across 67 Access VBA entries in the archive, the accepted answer here holds strong answer (top 25 %%) status — meaning voters are unusually aligned on the right fix.
The Verified Solution — strong answer (top 25 %%) (+15)
Advisory answer — community consensus with reference links
Note: the verified answer below is a reference / advisory response rather than a copy-ready snippet.
Use .Value instead – that doesn’t require setting focus first. From the documentation, for example for the TextBox control (emphasis mine):
While the control has the focus, the Text property contains the text
data currently in the control; the Value property contains the last
saved data for the control. When you move the focus to another
control, the control’s data is updated, and the Value property is set
to this new value. The Text property setting is then unavailable until
the control gets the focus again.
Loop-performance notes specific to this pattern
The loop in the answer iterates in process. On a 2026 Office build, setting Application.ScreenUpdating = False and Application.Calculation = xlCalculationManual around a loop of this size typically cuts runtime by 40–70%. Re-enable both in the Exit handler.
When to Use It — classic (2013–2016)
Ranked #20th in its category — specialized fit
This pattern sits in the 52% tail relative to the top answer. Reach for it when your scenario closely matches the question title; otherwise browse the Access VBA archive for a higher-consensus alternative.
What changed between 2013 and 2026
The answer is 13 years old. The Access VBA object model has been stable across Office 2013, 2016, 2019, 2021, 365, and 2024/2026 LTSC, so the pattern still compiles. Changes that might affect you: 64-bit API declarations (use PtrSafe), blocked macros in downloaded files (Mark-of-the-Web), and the shift toward Office Scripts for web-first workflows.