After the update projects including ms common controls 6 (MSCOMCTL.OCX) gave an 'Object library not registered' message during load (into IDE) and all progressbars etc. turned into picture boxes. The 'Object library not registered' message also appeared in a new IDE Project when trying to add the ms common controls 6 (MSCOMCTL.OCX)Component.
So I reverted to the Restore point made before the update and all worked normally again.
Very soon I was prompted to install the banished update again; I did and it was all 'Object library not registered' again.
So I opened C:\Windows\syswow64\ in a admin Command window and did regsrv32 MSCOMCTL.OCX
Which seems to to have fixed it.
Is anyone else having a strange day?

I had the same problem on my computer, but one of my devs didn't have any problems.

I'm running Windows 7, he is running Vista. Maybe this is the difference.

Anyway... your post saved me some time trying to figure this out. Thanks!

-George
Microsoft SQL Server MVP
My Blogs
SQLCop
twitter
"The great things about standards is that there are so many to choose from." - Fortune Cookie Wisdom

George - yes I forgot to say I got these probs on W7 64 bit, although strangely my XP machine seems ok.
A bit of Googling turned up this on the topic;
http://answers.microsoft.com/en-us/windows/forum/w...

and this in passing;
http://support.microsoft.com/kb/2708437 - MS12-060: Description of the security update for Visual Basic 6.0 Service Pack 6: August 14, 2012
Any feedback on whether we should go anywhere near this one would be appreciated.

If you always run the IDE elevated (as you were told to do by Microsoft back when Vista's support for the VB6 IDE was announced in 2006) you wouldn't have this problem.

Way too many people ignored the advice and rely on very poor "boildowns" of the issues like the sadly incomplete and misleading "forty pound head" blog post when installing VB6 into post-XP systems.

Your registry must be a mess of mismatched global and virtualized local component registration.


All of that aside, the big problem will be systems where you have applications deployed. Your development system is only the tip of the iceberg.

Microsoft isn't the company it used to be. In their race to the bottom the cheap employees they hire now create one broken security patch after another.

Hugh,

Would you explain what you mean by

Quote:

So I opened C:\Windows\syswow64\ in a admin Command window and did regsrv32 MSCOMCTL.OCX

I am having the same problem....

Thanks,

Ortho

"you cain't fix 'stupid'..."

Assuming Windows 7 - 64 bit
Click the Win7 Orb
Type cmd into the Search box - a Shortcut to cmd.exe will appear
Right click the cmd.exe Shortcut select Run as administrator - a Command prompt window appears titled 'Administrator Command prompt' the current folder on the prompt is C:\Windows\System32
Enter cd .. - to navigate back to C:\Windows
Enter cd syswow64 - to make that the current folder, then from the C:\Windows\Syswow64 prompt ...
Enter regsrv32 MSCOMCTL.OCX - a message will appear indicating success/ failure to register

There is a more complete fix at Fixing the Microsoft Windows Common Control Library (MSCOMCTL.OCX) Security Update though many can limp along with the partial fix as described above as well as by Microsoft in the KB articles (links to them on that page).

Hugh and especially dilettante,

The "fixing the MS..." document was perfect for fixing my problems on my 32 bit XP machine. Thank both of you for your help! Stars.

Ortho

"you cain't fix 'stupid'..."

We'll just have to take a deep breath and wait for the next thing they break.

>next thing they break
Looking on the bright side (at the moment) it seems that apps compiled to work with the old MSCOMCTL.OCX still seem to install/ work with the new one.

Do you mean "as long as the user jumps through these hoops" or something?

I guess I'm worried about (1.) what happens when an existing application is installed and then this update happens, and about (2.) what happens after the update is in place and working and you then install an application that has the old OCX in its package.

The first case probably means users calling for support (or just calling you names) when things stop working. They won't know they need to hold their noses and jump into the air and spin around 3 times.

For e second, a smart installer will see the new version and leave things alone - though a lot of them aren't that smart.

Is anyone calling you names yet?

So far so good here, but I have moved to using isolated assemblies whenever possible.

This has downsides (Windows Update security updates don't get automatically applied to isolated libraries) and upsides (Windows Update can't break my programs in most cases, nor can all of the really shabby "no-no setup" installers other people create).

The downside means I have to provide my own updates and get users to install them. So far though the benefits have been worth it.

One other point is that most of the "security vulnerabilities" Microsoft has uncovered in recent years are only serious threats for Web pages that use these ActiveX controls. Few of them have any impact on a VB6 program. Those "kill bits" you read about apply to IE.

Between the growing share of the market occupied by contrarian browsers and IE being more and more locked down hardly anyone tries to do that anymore anyway.