Since I am prepared for this case I simply copy the mscomctl.ocx from the directory "C:\Windows\SysWOW64" into the directory "C:\Program Files (x86)\Microsoft Office\root\vfs\SystemX86" (overwrite) and then the list views will work again (without re-registration via Regsvr32). He wroteĭirectory C:\Program Files (x86)\Microsoft Office\root\vfs\SystemX86 Sam left me a feedback to my German blog post, indicating, that FebruOffice updates are shipping also the wrong OCX version. Register the OCX by RegSvr32 "C:\Windows\SysWOW64\MSCOMCTL.ocx".Īfter a re-registration of the replaced.Place an earlier version of the OCX () into C:\Windows\SysWOW64.Delete the OCX file from C:\Windows\SysWOW64 folder.Unregister the OCX by RegSvr32 /u "C:\Windows\SysWOW64\MSCOMCTL.ocx" in C:\Windows\SysWOW64.Within this Technet thread similar issues with Microsoft Office 365 ProPlus Build 10730.20264 and MSCOMCT.ocx are discussed. Probably because about 2 years ago the same misery has already happended. With the other Office versions I found absolutely no hints at Microsoft which patch will deliver the wrong MS Common Controls file version in Dec 2018 or Jan 2019. A manual deinstallation of the respective update is not possible. With Office 2019 C2R this is especially stupid, because there is only a new build. I have noticed that Microsoft delivers another wrong file version of the MS Common Controls (mscomctl.ocx) with the Office January 2019 updates. Blog reader Sam sent me the following text. I guess something like that happened again. In the past, Microsoft has always 'managed' it to use such updates to accidentally kill office add-ins or VB programs. The problem is that if the version numbers of the TypeLibs are changed, all Visual Basic and VBA applications that use these TypeLibs will no longer run. Unfortunately this breaks the compatibility. Microsoft has once again annoyed developers with the MS16-004 update, as it incremented the version of the typelibs of MsComCtl.ocx. At that time I had received the following information from a blog reader. The MS16-004 from 2017 update obviously leads to considerable compatibility issues with VB6 and VBA applications. So I'm wondering about best practices to avoid issues due to version mismatch of MSCOMCTL.I had discussed this case in the 2017 within my German blog post Januar-Update MS16-004 bricht MSComCTL.ocx. I try to avoid distributing MSCOMCTL.OCX to clients machines. Tag = "_UpdateAdressberichtStaging12, =. LvStoredProc.SmallIcons = Me!StandardImagelist!StandardImagelist.Object Set lvStoredProc = Me!ListViewStoredProc.Object 'Dim lvStoredProc As ListView, lItem As ListItemĭim lvStoredProc As Object, lItem As Object My Access application has no code reference to MSCOMCTL.OCX and I use late binding in my VBA code: I was able to reproduce the error by replacing MSCOMCTL.OCX on my machine with version "The expression On MouseMove you entered as the event property setting produced the following error: A problem occurred while Microsoft Access attempting to load an ActiveX Control into your forms or reports."Ħ.1.98.39, the version on my machine 6.1.98.46. My client is getting errors when opening a form with a listview control, e.g That I referenced from Microsoft Windows Common Controls 6.0 (Service Pack 6), i.e. I have an existing Access 2013 application with several forms and Listview controls
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |