Determine whether a Access checkbox is checked or not

The Problem (Q-score 14, ranked #6th of 67 in the Access VBA archive)

The scenario as originally posted in 2010

Such a simple question, but I cannot find the answer (Google, MS help, SO):

How can I check by VBA whether an unbound checkbox on an Access form is checked by the user or not? Can’t find the right property.

Thanks in advance!

UPDATE:

I used this code after the suggestions of @HansUp and @RC:

Private Sub CmdTest_Click()
    MsgBox "Check1.Value = " & Me.Check1.Value
    MsgBox "Check2.Value = " & Me.Check2.Value
End Sub

Private Sub Form_Load()
    Me.Check1.Value = 25
    Me.Check2.Value = 50
End Sub

2nd UPDATE:

The code should be this (thanks to @David-W-Fenton):

Private Sub CmdTest_Click()
    If Me.Check1 = True Then
        MsgBox "Check1 IS CHECKED"
    Else
        MsgBox "Check1 IS NOT CHECKED"
    End If
    If Me.Check2 = True Then
        MsgBox "Check2 IS CHECKED"
    Else
        MsgBox "Check2 IS NOT CHECKED"
    End If    
End Sub

Private Sub Form_Load()
    ' set first checkbox default checked
    Me.Check1.Value = True 
    ' set second checkbox default unchecked
    Me.Check2.Value = False
End Sub

Why the Win32 API declaration is fragile here

This problem involves a Declare statement, which means 32-bit vs 64-bit compatibility is in play. Office 64-bit requires the PtrSafe keyword and LongPtr data types for any handles — the most common root cause of the exact symptom described.

The Verified Solution — strong answer (top 25 %%) (+15)

3-line Access VBA pattern (copy-ready)

Checkboxes are a control type designed for one purpose, to insure valid entry of Boolean values.

In Access, there are two types:

1. 2-state — can be checked or unchecked, but not Null. Values are True (checked) or False (unchecked). In Access and VBA the value of True is -1 and the value of False is 0. For portability with environments that use 1 for True, you can always test for False or Not False, since False is the value 0 for all environments I know of.

2. 3-state — like the 2-state, but can be Null. Clicking it cycles through True/False/Null. This is for binding to an integer field that allows Nulls. It is of no use with a Boolean field, which can never be Null.

Minor quibble with the answers:

There is almost never a need to use the .Value property of an Access control, as it’s the default property. These two are equivalent:

  ?Me!MyCheckBox.Value
  ?Me!MyCheckBox

The only gotcha here is that it’s important to be careful that you don’t create implicit references when testing the value of a checkbox. Instead of this:

  If Me!MyCheckBox Then

…write one of these options:

  If (Me!MyCheckBox) Then  ' forces evaluation of the control

  If Me!MyCheckBox = True Then

  If (Me!MyCheckBox = True) Then

  If (Me!MyCheckBox = Not False) Then

Likewise, when writing subroutines or functions that get values from a Boolean control, always declare your Boolean parameters as ByVal unless you actually want to manipulate the control. In that case, your parameter’s data type should be an Access control and not a Boolean value. Anything else runs the risk of implicit references.

Last of all, if you set the value of a checkbox in code, you can actually set it to any number, not just 0 and -1, but any number other than 0 is treated as True (because it’s Not False). While you might use that kind of thing in an HTML form, it’s not proper UI design for an Access app, as there’s no way for the user to be able to see what value is actually be stored in the control, which defeats the purpose of choosing it for editing your data.

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 — vintage (14+ years old, pre-2013)

A top-10 Access VBA pattern — why it still holds up

Ranks #6th of 67 in the Access VBA archive. The only pattern ranked immediately above it is “OleDbCommand parameters order and priority” — compare both if you’re choosing between approaches.

What changed between 2010 and 2026

The answer is 16 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.