none
Problem with ActiveX Control on Form (Access 2007)

    Question

  • I have a 10-year old application, which has been upgraded over the years, and is currently running in Access 2007.  It is installed on 5 PCs in the same company.

    All of a sudden, when the users open a particular form, they get one error message or another, but both error messages end with the text "There was an error loading an ActiveX control on one of your forms or reports".

    On one of the PCs, a Compact and Repair seemed to help, but not on any of the others.  I'm thinking an OS patch may have messed something up, or a software install that I'm unaware of.

    The form in question uses 2 ActiveX controls, a ListView and a DatePicker control.  Each of these require their own OCX to be loaded and registered.

    Does anybody have any experience with a similar issue?  Any ideas on how to proceed?  Presumably, if I identified and reinstalled the pertinent control set (which should re-register its OCX), that may help.

    Any ideas?  Thanks a LOT for any help.


    Ron Mittelman

    Thursday, August 16, 2012 7:36 PM

Answers

  • Hi Ron,

    There have been some issues reported after security update MS12-060 was installed and it looks like KB articles 2748410 and 2687441 appear to be related to your scenario.

    2748410             Security Update MS12-060 Impairs Functionality of Access Database

    http://support.microsoft.com/kb/2748410/EN-US

    2687441             MS12-060: Description of the security update for 2007 Office system: August 14, 2012

    http://support.microsoft.com/kb/2687441/EN-US

    The security update puts a newer version of the mscomctl.ocx file onto your machine, so before going through the steps in KB 2748410 I would recommend you have the security update installed (the security update would be the one in KB 2687441).  If you have this installed, but overwrote the mscomctl.ocx file on your machine, you will want to make sure you put a copy of the latest version of the control back onto the machine.  The version should be 6.01.9834 and on a 32 bit machine this should be found in your system32 folder and on a 64 bit machine it should be located in the syswow64 folder.  Once you have the update installed and the latest version of the control on the machine, I would recommend going through all the steps in KB 2748410 to see if they help. 

    Best Regards,

    Nathan O.

    Microsoft Online Community Support


    Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    • Marked as answer by RMittelman Tuesday, August 28, 2012 4:13 PM
    Monday, August 27, 2012 4:15 PM
    Moderator
  • If you're still having problems, see what Luke Chung posted in Fixing The Microsoft Windows Common Control Library (mscomctl.ocx) Security Update, Access 2010    

    Doug Steele, Microsoft Access MVP
    http://www.AccessMVP.com/djsteele (no e-mails, please!)
    Co-author Access Solutions — Tips, Tricks, and Secrets from Microsoft Access MVPs (ISBN 978-0-470-59168-0)

    • Marked as answer by RMittelman Tuesday, August 28, 2012 4:13 PM
    Monday, August 27, 2012 9:00 PM

All replies

  • Hello Ron:

    I have encountered your issue on client computers many times.... Especially with the newer date picker and the legacy calendar control.  First of all, NONE of the Active-X controls work in the 64 bit version of Office.  If you still are running the 32 bit versions, then you may need to re-copy the ocx files to the correct directories and then re-register them.  It is such a common issue that I have posted the workarounds on my web site:

    Using The Legacy Calendar Control

    Using The Date Picker

    Even through my site post was directed at Excel, it's the exact same issue for Access.

    Regards,


    Rich Locus, Logicwurks, LLC

    http://www.logicwurks.com


    • Edited by RichLocus Thursday, August 16, 2012 8:10 PM
    Thursday, August 16, 2012 8:07 PM
  • Hello:

    One more comment.  If you want to verify which component is Missing, go to the VBE (Visual Basic Editor), select Tools, References and look for the word "MISSING".  It will direct you to the component that didn't load.

    Regards,


    Rich Locus, Logicwurks, LLC

    http://www.logicwurks.com

    Thursday, August 16, 2012 8:19 PM
  • Hi Rich,

    Thanks so much for the quick reply.  I won't be able to check this out until tomorrow, but wanted to let you know I saw your posts.  I am assuming I'm still using 32-bit software.  3 of the 5 PCs are still running Windows XP, and 2 are running Win 7.  I'm not even sure how to tell which version (32/64).  But, since all were working fine until just a day or 2 ago, I'm guessing 32-bit version.  I first suspected a software install over-wrote one of my OCXs with a newer version which caused the problem.  I don't think that's the case now, unless an auto-applied MS patch did it.

    Also, I don't think it's a broken reference because the user can see the ListView control on the form under the error message, and they can see the DatePicker on another form.  If the reference was broken, wouldn't it make the control's invisible, or replaced by blank controls?  I've had that happen in the past.

    I initially suspected the DatePicker, because I've had issues with it in the past.  Now I suspect the ListView instead, because the user tells me when the form comes up, after dismissing the error message, the ListView doesn't "work".  By this I mean that the result of clicking a ListItem, which should be bringing another record up on the form, does not happen, and they get the error messagae again.  I believe the error message mentions an event, either Click or Mouse_Move, they weren't specific.

    So, is it possible for the reference to the ListView control OCX be missing, but the control still shows?  Seems odd.  Also, it happened to several PCs at the same time.  One of them was fixed by compact and repair, but the others weren't.  I don't know the auto-update status on the machines, regarding MS pushes.

    Do you by any chance have instructions anywhere regarding ListView control fixing?  I am in the process of re-writing the app without any ActiveX's, but that doesn't help this problem.  I need to fix it.

    Thanks again for your quick response...


    Ron Mittelman

    Thursday, August 16, 2012 9:17 PM
  • Ron:

    I don't have anything new on ListView, but if all else fails, sometimes strange problems can be corrected by creating a shortcut to the Access file and running the decompile.

    The shortcut string looks like this for Access 2003:

    Target:  "C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE" "C:\XTemp\OTSReportBySizeAndDateV84.mdb" /decompile

    Start In:  "C:\Program Files\Microsoft Office\OFFICE11"

    Regards,


    Rich Locus, Logicwurks, LLC

    http://www.logicwurks.com

    Thursday, August 16, 2012 10:40 PM
  • Hey Rich,

    Ok, strangeness abounds here.  I removed references to MSComCtl and MSComCtl2, which are described as Microsoft Windows Common Controls 6 and Microsoft Windows Common Controls-2 6 respectively, and are for the ListView and DatePicker respectively.

    I tried to add the references back, and couldn't find them in the list.  I downloaded the common controls ocx and installed.  Still couldn't find it in the references list. So I browsed, and found the mscomctl.ocx, and added it back in.  The app seemed to work, but when I closed it and opened it again, it stopped working.

    It blows up only when I open a particular form.  Then, I get a mouse_move error if I hover over the ListView, or a click event error if I click the exit button on the form.  Both error descriptions end with the text: "Object or Class does not support the set of events".  This is slightly different than the errors I was getting yesterday.

    So, I went to Add/Remove programs, and chose to repair Office.  It took a while, then needed a reboot, then the program worked fine.  For a while...  I repeatedly opened and closed the particular form, and browsed various records by clicking various ListView items, then finally it stopped working again and gave the error mentioned above.

    I haven't yet tried the decompile.  Do you think that will help?  Also, strange thing is that I never replaced the reference to mscomctl2.ocx, which I believe the DatePicker depends on, but that control still works ok.

    What the heck is going on here?

    Thanks...


    Ron Mittelman

    Friday, August 17, 2012 4:57 PM
  • Ron:

    I have seen the decompile work miracles.  I would try it.

    Regards,


    Rich Locus, Logicwurks, LLC

    http://www.logicwurks.com

    Friday, August 17, 2012 5:05 PM
  • Hi Rich,

    Thanks for all of the help, and sorry for the delay in answering your last post.

    A lot has happened regarding this issue.  The customer decided that in parallel with me trying to solve the issue, they would pay Microsoft to solve it.  They called MS support, and for a paltry $200 per PC, Microsoft uninstalled Office, reinstalled, and I know not what else.  This on 4 different PCs.  The problem seemed to be solved.  Seemed being the operative word.  About 2 business days later, it reoccurred.  They contacted MS again, who promptly told them it was a coding error (this on an app that has worked for years, and all of a sudden stopped working, with no coding changes).  They thought this because of the error message, which mentions a keydown event.  They weren't smart enough to see that ANY event triggers the error, even the mouse move event when you cursor over the ListView.  Neither of those events have any code behind them.  Meantime, MS is not even listening to our suggestion that it may be an OCX/DLL issue.

    We did discover a workaround:  When the error comes up, click OK as many times as needed, then change the view to design view.  Click ok if the error comes up again. Then change back to form view, and it seems to work fine, until the next time you load the form.

    This got me thinking, and I changed the switchboard command from opening a form to running a macro. I created a macro to open the form in design view, then open it again in form view.  On my PC (a virtual Win7 in VMWare Fusion on my MacBook Pro), this seems to work reliably.  I will test this with customer on one PC, and see if it suffices.

    It doesn't actually solve the issue, but a decent workaround.  I still think the problem is a mismatch in OCX/DLL versions, or some other esoteric reason.  Does anything I added here ring any bells?  Thanks again for all of your help.


    Ron Mittelman

    Monday, August 27, 2012 3:53 PM
  • Hi Ron,

    There have been some issues reported after security update MS12-060 was installed and it looks like KB articles 2748410 and 2687441 appear to be related to your scenario.

    2748410             Security Update MS12-060 Impairs Functionality of Access Database

    http://support.microsoft.com/kb/2748410/EN-US

    2687441             MS12-060: Description of the security update for 2007 Office system: August 14, 2012

    http://support.microsoft.com/kb/2687441/EN-US

    The security update puts a newer version of the mscomctl.ocx file onto your machine, so before going through the steps in KB 2748410 I would recommend you have the security update installed (the security update would be the one in KB 2687441).  If you have this installed, but overwrote the mscomctl.ocx file on your machine, you will want to make sure you put a copy of the latest version of the control back onto the machine.  The version should be 6.01.9834 and on a 32 bit machine this should be found in your system32 folder and on a 64 bit machine it should be located in the syswow64 folder.  Once you have the update installed and the latest version of the control on the machine, I would recommend going through all the steps in KB 2748410 to see if they help. 

    Best Regards,

    Nathan O.

    Microsoft Online Community Support


    Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    • Marked as answer by RMittelman Tuesday, August 28, 2012 4:13 PM
    Monday, August 27, 2012 4:15 PM
    Moderator
  • Nathan, you da man!

    This "seems" to have solved the issue.  I say "seems" because I just tested it on my virtual Win7 machine, and I think it worked.  As mentioned in my last post, when getting the error, then going into design mode and back to form view sort-of fixes the problem.  My customer says this works until you exit the form and come back.  In my case, it worked even after closing the form on my system.  I checked in Add-Remove Programs (or whatever it's called in Win7) and I have that security update installed.  I checked the version of mscomctl.ocx, and it is the version you mention.  I did unregister and reregister in admin command prompt, and now it seems to work without the extra step of opening in design view then in form view.  I just put condition "False" on that first line of my macro, and all works ok.

    I will try to update this on a customer PC today after verifying the security update and version of ocx.  If this works, I'll mark your answer as "the one".  Thanks...


    Ron Mittelman

    Monday, August 27, 2012 6:12 PM
  • If you're still having problems, see what Luke Chung posted in Fixing The Microsoft Windows Common Control Library (mscomctl.ocx) Security Update, Access 2010    

    Doug Steele, Microsoft Access MVP
    http://www.AccessMVP.com/djsteele (no e-mails, please!)
    Co-author Access Solutions — Tips, Tricks, and Secrets from Microsoft Access MVPs (ISBN 978-0-470-59168-0)

    • Marked as answer by RMittelman Tuesday, August 28, 2012 4:13 PM
    Monday, August 27, 2012 9:00 PM
  • It seems this remains an issue in the prerelease 2013 as well.

    Chris Ward

    Tuesday, August 28, 2012 1:58 PM
  • Thank you for the update!  This problem really has me pulling my hair out.

    I have a system with an Access front end deployed to roughly 300  users.  As the users are getting this latest patch, the problem is beginning to appear.  Unfortunately, I don't have admin rights to all these machines, nor do the users.

    Do you know if or when a new patch will be deployed to solve this problem?

    Thank you,

    MrXmas

    Tuesday, August 28, 2012 1:59 PM
  • While I definitely don't know definitively, I wouldn't be surprised if no new patch was released. COM has been considered obsolete technology for a few years now, so I can't see Microsoft caring much that they've broken compatibility with it.


    Doug Steele, Microsoft Access MVP
    http://www.AccessMVP.com/djsteele (no e-mails, please!)
    Co-author Access Solutions — Tips, Tricks, and Secrets from Microsoft Access MVPs (ISBN 978-0-470-59168-0)

    Tuesday, August 28, 2012 3:00 PM
  • Going Forward,

    what should we be using instead?


    Chris Ward

    Tuesday, August 28, 2012 3:52 PM
  • I'm not that familiar with all the details of Win7.  It is possible that the fix can be applied without admin rights.  As mentioned in KB 2748410, unregistering and reregistering *may* fix it.  The article also shows a further registry fix in case unregistering / registering doesn't do the trick.  The above suggestion and link provided by Douglas seemed to work fine on my user's Win7 PC.  You should figure out how to get admin rights to those PCs you don't have it on.  Perhaps IT department can help you?

    Ron Mittelman

    Tuesday, August 28, 2012 4:01 PM
  • Darn good question! The Access MVPs do hammer on Microsoft about things like this, but their current mandate is pretty much web-oriented. (In all fairness, with a product as large as Access, it's pretty much impossible to try and work on all areas at once, so it makes sense to concentrate on only specific areas at any given point in time.) 

    You could take a look at TList, from Bennet-Tec. (I have no affiliation with them.) It's been several years since I looked at their product, and it's possible that it could have similar issues, but it's certainly capable of providing pretty nifty interfaces!


    Doug Steele, Microsoft Access MVP
    http://www.AccessMVP.com/djsteele (no e-mails, please!)
    Co-author Access Solutions — Tips, Tricks, and Secrets from Microsoft Access MVPs (ISBN 978-0-470-59168-0)

    Tuesday, August 28, 2012 4:03 PM
  • Thanks Douglas.  This worked on one of my customer's PCs.  I am waiting for them to test it further before deploying it to others.  This was a life-saver.

    Ron Mittelman

    Tuesday, August 28, 2012 4:13 PM
  • Of the 5 PCs my customer has, the fix mentioned above worked on 4 of them.  The 5th one still exhibits the bad ActiveX behavior described.

    Since the work-around of changing to design view and back to form view seems to work, I implemented it by changing the switchboard command on that PC from "Open Form" to "Run Macro".  I created a macro to first open the form in design view, then immediately open it in form view.  This seems to work.

    I am confused by the inconsistency of the results of the "real" fix, but this will work for now.


    Ron Mittelman

    Thursday, August 30, 2012 6:38 PM
  • Hi Ron,

    The following articles now have a FixIt utility within them that you could also try running.  You will still need to install the actual security update before running the FixIt utility.

    Security Update KB Articles:
    2597986                MS12-060: Description of the security update for Office 2010: August 14, 2012
    http://support.microsoft.com/kb/2597986/EN-US
     
    2687441                MS12-060: Description of the security update for 2007 Office system: August 14, 2012
    http://support.microsoft.com/kb/2687441/EN-US
     
    2687323                MS12-060: Description of the security update for Office 2003 and Office 2003 Web Components: August 14, 2012
    http://support.microsoft.com/kb/2687323/EN-US


    Best Regards,
    Nathan O.
    Microsoft Online Community Support


    Friday, August 31, 2012 2:10 PM
    Moderator
  • Thanks for the info Nathan.  I will try running the fixit next week when I see the customer.  I'm not sure what you mean by needing to run the actual security update first.  Presumably it's been run, that's how we got into this mess.  Do you mean I need to run it a second time?

    Thanks...


    Ron Mittelman

    Friday, August 31, 2012 2:16 PM
  • Hi Ron,

    If you already have the security update installed, then you don't need to install it again.  You can just run the FixIt.  I just mentioned that for others that read the post to ensure the security update is applied before running the FixIt.

    Best Regards,
    Nathan O.
    Microsoft Online Community Support


    Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.


    Friday, August 31, 2012 3:55 PM
    Moderator