The knowledge base blog https://staging.esdm.co.uk/knowledge http://www.rssboard.org/rss-specification mojoPortal Blog Module en-GB 120 no Windows updates break MS Common Controls Tree Control This is a replacement blog-post, based on our developing understanding of the problem and users' experiences. It appears that the update that disrupts the operation of 'tree' controls in HBSMR v3 and v4 is Security Update MS12-060. Symptoms include inability to select items in a tree or, in the case of v3, an inability to add new MonTypes, Components etc. The problem relates to the version and registration of mscomctl.ocx

Microsoft has now published guidance on how to resolve this issue. Please see:

http://support.microsoft.com/kb/2748410

 

 


Crispin Flower  ...]]> https://staging.esdm.co.uk/windows-updates-break-ms-common-controls-tree-control crispin.flower@idoxgroup.com (Crispin Flower) https://staging.esdm.co.uk/windows-updates-break-ms-common-controls-tree-control https://staging.esdm.co.uk/windows-updates-break-ms-common-controls-tree-control Thu, 16 Aug 2012 08:42:00 GMT ACCDE problems on Access 2010 (and Access 2010 SP1) We’ve had a bit of bother over the past few weeks, where an Access application compiled as an .accde file in Access 2010 would not run on other machines. The error messages encountered varied depending on whether the machine was running full Access or runtime. One of the messages was…

The database cannot be opened because the VBA project contained in it cannot be read. The database can be opened only if the VBA project is first deleted. Deleting the VBA project removes all code from modules, forms and reports. You should back up your database before attempting to open the database and delete the VBA project.
To create a backup copy, click Cancel and then make a backup copy of your database. To open the database and delete the VBA project without creating a backup copy, click OK.

…and this had me thinking my Office installation was corrupted or something.

But the most common message was along the lines of …

"Undefined Function <FunctionName> in Expression…"

… which made me think I had picked up a reference in my application that was missing from the target machines. I thought perhaps it was because I was using Windows 7 64-bit and the target machines were running 32-bit XP or Vista/7.

After trying many permutations, combinations, and perambulations, I ruled out both of the above, then stumbled upon the real issue…

As described in this Microsoft support article, an ACCDE that is compiled on Office 2010 SP1 will be incompatible with a machine running Office 2010 RTM (i.e. without the service pack). It turned out my machine was running 2010 SP1, whereas the target machines where the application failed were running 2010 RTM.

Once everyone is on the same SP, the problem vanishes.

And I think my confidence is restored that there should be no problem moving an application between 32- and 64-bit, Windows XP, Vista or 7, as Access automatically finds its core references, plus any custom ones so long as they on a PATH or in the application folder.

Incidentally, it’s not immediately obvious whether or not you have SP1 (which comes down in Windows updates). One way (in any Office app) to tell is to go to File > Help >  About Microsoft Access (or whatever) > Additional Version and Copyright Information, which will show SP1 in the top line if you have it:

About Microsoft Access window
Crispin Flower  ...]]> https://staging.esdm.co.uk/accde-problems-on-access-2010-and-access-2010-sp1 crispin.flower@idoxgroup.com (Crispin Flower) https://staging.esdm.co.uk/accde-problems-on-access-2010-and-access-2010-sp1 https://staging.esdm.co.uk/accde-problems-on-access-2010-and-access-2010-sp1 Sat, 11 Feb 2012 19:56:38 GMT