ActiveX Controls in Access: What Breaks After Migration and How to Fix It

Open a legacy Access database on a modern Windows machine and you may be greeted with a form that looks like Swiss cheese — blank boxes where controls used to be, errors about missing objects, or a security prompt that refuses to load anything. Most of the time, the culprit is ActiveX. This guide explains why ActiveX controls break in Access after migration, which ones are fixable, and how to replace the ones that aren't.

Why ActiveX Controls Break

ActiveX controls are COM components — small .ocx or .dll files registered in the Windows Registry that Access loads at runtime to render controls like calendars, list boxes, date pickers, and charts. They were the standard extensibility mechanism for Office applications in the late 1990s and early 2000s.

The problem is threefold:

• 32-bit vs 64-bit: Most legacy ActiveX controls are 32-bit. Modern Windows 11 with 64-bit Office requires 64-bit compatible controls. A 32-bit OCX cannot load in a 64-bit Office process.
• Abandoned controls: Many controls were shipped by Microsoft or third-party vendors who no longer support them. They were never updated for 64-bit.
• Missing registration: When Office is reinstalled, upgraded, or migrated to a new machine, the OCX files and their registry entries don't always follow.

The Calendar Control: Most Common Casualty

If your Access database uses a calendar control for date selection, it's almost certainly MSCAL.OCX — the Microsoft Calendar Control. This was removed in Office 2010 and doesn't exist on any modern Office installation. If you're still using it, your date picker forms show a blank box or throw "Cannot find the installable ISAM" or "Object library invalid" errors.

Replacing MSCAL.OCX

The simplest replacement for the calendar control is Access's built-in Date Picker, which was added in Access 2010. To add it to a form:

1. Open the form in Design View.
2. Delete the existing Calendar Control placeholder.
3. In the Form Controls toolbox, select the Text Box tool.
4. Draw a new text box where the calendar was.
5. Set the Format property of the text box to Short Date.
6. In the property sheet, set Show Date Picker to For dates.

This gives you a built-in date picker with a calendar popup — same user experience, no external dependency, and it works on all modern Access versions. Update the VBA code that referenced the old calendar control to reference the new text box's Value property instead.

Common ActiveX Controls and Their Status

Control	File	Status on Modern Office	Replacement
Calendar Control	MSCAL.OCX	Removed in Office 2010	Built-in Date Picker text box
Common Dialog	COMDLG32.OCX	32-bit only — breaks on 64-bit	VBA FileDialog object
Winsock Control	MSWINSCK.OCX	32-bit only — breaks on 64-bit	WinHTTP or XMLHTTP in VBA
ListView/TreeView	MSCOMCTL.OCX	Updated version available	Re-register updated MSCOMCTL.OCX
Status Bar	MSCOMCTL.OCX	Updated version available	Re-register updated MSCOMCTL.OCX
Progress Bar	MSCOMCTL.OCX	Updated version available	Re-register updated MSCOMCTL.OCX
ImageList	MSCOMCTL.OCX	Updated version available	Re-register updated MSCOMCTL.OCX
Toolbar	MSCOMCTL.OCX	Largely replaced by Ribbon	Access Ribbon or custom toolbar form
RichTextBox	RICHTX32.OCX	32-bit only	Access Long Text / Memo field with formatting
Web Browser	SHDOCVW.DLL	Works but Edge-based in Win11	Usually fine; test rendering

Fixing MSCOMCTL.OCX (ListView, TreeView, ProgressBar)

MSCOMCTL.OCX is one of the more salvageable legacy controls. Microsoft released an updated 64-bit-compatible version. If your ListView or TreeView controls are showing as broken, the fix is usually to re-register the updated version of the OCX:

REM Run as Administrator in Command Prompt:
regsvr32 /u "C:\Windows\SysWOW64\MSCOMCTL.OCX"
regsvr32 "C:\Windows\SysWOW64\MSCOMCTL.OCX"

If the OCX is missing entirely, you can obtain the updated version through the Microsoft Download Center (search "MSCOMCTL.OCX 64-bit"). After re-registration, your ListView and TreeView controls should reappear in Access forms without any code changes.

Replacing Common Dialog with VBA FileDialog

The Common Dialog control (COMDLG32.OCX) was used to show file open/save dialogs. It's 32-bit only and doesn't work on 64-bit Office. The replacement is the built-in Application.FileDialog object, which has been available since Access 2002 and works on all modern versions:

Dim fd As FileDialog
Set fd = Application.FileDialog(msoFileDialogFilePicker)
With fd
    .Title = "Select a File"
    .AllowMultiSelect = False
    .Filters.Clear
    .Filters.Add "All Files", "*.*"
    If .Show = -1 Then
        MsgBox "Selected: " & .SelectedItems(1)
    End If
End With

Replace any code that instantiated a CommonDialog object with this pattern. The user experience is identical — the same Windows file picker dialog appears.

How to Audit Your Database for ActiveX Dependencies

Before migrating, inventory every form and report that uses an ActiveX control. Open each form in Design View and look for controls with a "broken" placeholder appearance — they'll show as grey boxes with an X, or you'll see an error in the property sheet reading "Object class not registered." Make a list of the control name and its ProgID (found in the control's OLE Class or Control Source property).

You can also query the database programmatically:

Dim db As DAO.Database
Dim frm As Access.Form
Dim ctl As Access.Control

Set db = CurrentDb
For Each frm In CurrentProject.AllForms
    DoCmd.OpenForm frm.Name, acDesign
    For Each ctl In Forms(frm.Name).Controls
        If ctl.ControlType = acObjectFrame Or ctl.ControlType = acBoundObjectFrame Then
            Debug.Print frm.Name & " > " & ctl.Name & " : " & ctl.OLEClass
        End If
    Next ctl
    DoCmd.Close acForm, frm.Name
Next frm

This prints every OLE/ActiveX control name and class identifier across all forms. Cross-reference the classes against the table above to know which ones need replacement before migration.

After Migration: Verifying Controls Are Working

Once you've migrated to .accdb and replaced or re-registered your ActiveX controls, test every form that had a control dependency:

1. Open each affected form in normal (not Design) view.
2. Interact with every control — click date pickers, expand tree views, load file dialogs.
3. Check the VBA event handlers that reference the old control — ensure property names still match the replacement control.
4. Run the database on a clean machine (no pre-existing registrations) to confirm nothing depends on your development environment's registrations.

For more on the complete migration process, see the Complete Guide to Access Database Migration. To understand how Access VBA needs to be audited alongside form controls, read the Access VBA Audit guide.

← Back to all posts