Steven Pybus
2026-08-25T00:20:33Z
Greetings!

I've been using the 32-bit ActiveX iGrid 5.0 control embedded in a form in Excel to manage my team's work queue. It has been working tremendously for a long time. I believe I started using it in 2012 (my username was spybus but I couldn't get a reset password email to send so I created this account.)

Beginning this week, any spreadsheet that referenced the control quit loading. The demo exe still runs though.

The error message is a Microsoft Visual Basic for Applications dialogue that says "System Error &H80004005 (-2147467259). Unspecified error".

What do you suggest is my best option to get up and running again?

Regards,
Steven P.
Steven Pybus
2026-08-25T02:06:28Z
I just installed the 7.5 Demo on a different PC with 64bit Excel. A non-domain computer without all of the corporate restrictions that we have at my work now. I referenced iGrid750_10Tec_win64.ocx (10Tec iGrid 7.5 Modern (32/64 bits)), added the control to a form and pressed play. I got the same error as at the office.

My work PC is a Windows 10 with 32bit Office. This one here at home is Windows 11 with 64bit Office.

I'm beginning to believe there was some kind of update to Office that the control isn't liking.

Steven Pybus
2026-08-25T03:35:44Z
I found your article on rolling back an Office update and decided to give it a try. I rolled both machines back from Office Version 2608 to 2607. The 64bit here at home and the 32bit at the office. Both machines are now able to load and run the ocx control.

I'm hopeful that you will produce an update that will be compatible with version 2608 and future Office updates.

Regards,
Steven P.
Igor/10Tec
2026-08-25T11:24:29Z
Another customer reported the same problem about a week ago. His Excel VBA application using iGrid ActiveX 5 stopped working in the same way following an upgrade of Office to Version 2608.

An initial cursory investigation into the issue with my AI assistants, which I use for development, suggests that the problem may be linked to the tightening of security policies regarding ActiveX in Microsoft Office, which is being rolled out in stages across its various versions. See also this post:

ActiveX will be disabled by default in Microsoft Office 2024 

Please note that the ability to use ActiveX components is now disabled by default and must be explicitly enabled in the Trust Center:

File → Options → Trust Center → Trust Center Settings → ActiveX Settings → select "Prompt me before enabling all controls with minimal restrictions"

We will continue to look for a solution to the problem or at least some kind of explanation, and as soon as we have new information, we will post it here. But for now, it seems clear that this is most likely not an iGrid issue.
Steven Pybus
2026-08-25T17:18:34Z
Thanks for the response! I appreciate your support for this valuable resource.
Igor/10Tec
2026-08-31T14:26:10Z
I ran a lot of tests with various ActiveX controls on different PCs (Windows 10/11, 32-bit and 64-bit Microsoft Office). Here’s what we know about the issue so far.

1) The problem occurs only in VBA UserForms in Microsoft Word and Excel. All is ok with iGrid in Microsoft Access.

2) I have tested the following editions and versions of iGrid ActiveX: Classic Edition – 2.5, 5.0, 7.5, Modern Edition – 7.5. This issue affects all of these editions and versions. Note that the Classic Editions were built with VB6, Modern Editions – with twinBASIC (2 different IDEs and runtimes).

3) I also tested the Classic and Modern Editions of our ImageList ActiveX control of the version 2.5. Here's an interesting fact: the problem only affects the Classic Edition (the 32-bit version only), but not the Modern Edition (both the 32-bit and 64-bit versions).

4) A simple ActiveX control built from the provided twinBASIC template works ok in 32-bit and 64-bit editions of Microsoft Office.

5) The classic 32-bit Microsoft ListView ActiveX control also works well in the 32-bit edition of Microsoft Office.

6) Adding debug code with MsgBox messages to the ImageList project helped us determine that the problem occurs before the first line of custom code in this ActiveX control is executed (the UserControl Initialize, InitProperties, and ReadProperties events). This suggests that the problem occurs somewhere outside the iGrid ActiveX control within the Microsoft Office VBA runtime environment.

We also know that, for now, the only way to get the iGrid ActiveX control to work in UserForms is to roll back from Office version 2608 to version 2607.

With all these facts in hand, I’ll continue working on this issue. Of course, I'll post here right away as soon as any new information about the issue becomes available.
Igor/10Tec
2026-09-01T09:16:04Z
More Office users report similar issues with other ActiveX controls:

Office version 2608 causing issues with VBA using ActiveX Objects 

So I don't think the problem lies with iGrid itself.
Igor/10Tec
2026-09-02T08:44:22Z
Wayne Phillips, the creator of twinBASIC, suggested adding logging to the latest versions of iGrid and ImageList (twinBASIC allows this) and using AI to compare the logs of iGrid and ImageList when they are used in VBA UserForms. Here is the brief result of that comparison using Claude:

Under Office 2608, MSForms fails to re-instantiate and IPersistStreamInit::Load a control from its own just-saved stream during the UserForm add/persist round-trip. Save completes successfully; the subsequent re-CreateInstance+Load never occurs and the host raises 0x80004005.

In other words, the fault is outside of the iGrid code.
Igor/10Tec
2026-09-03T06:32:49Z
Microsoft released Build 20326.20132 for Version 2608 of the Office on September 1st. I installed this update to check whether it fixes the problem with iGrid ActiveX. Yes, the problem has been fixed!
Steven Pybus
2026-09-04T03:05:08Z
This is great news. Thank you for your diligence in searching for a cause/solution.
Igor/10Tec
2026-09-04T06:20:04Z
One more point related to the official procedure for rolling back to a previous version of Office, as described in this Microsoft article:

How to revert to an earlier version of Office 

This article does not mention that the described rollback procedure "locks" your version of Office, and you will no longer be able to automatically update to a new version if you re-enable updates and select Update Options > Update Now in the Office interface. In my case I solved this problem by deleting the UpdateToVersion value from the registry key

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration

Hope this helps others too.