Printable View
These last few days I can't load some special controls, for example if I select Microsoft Windows Common Controls as in the screenshot:
Attachment 112437
I get the message "Object library not registered"
and the message perists after I register the ocx, even if I run cmd in elevated mode.
These are not 64bits components, so the should not be in SysWOW64!!
Counterintuitively enough, SysWow64 is the 32-bit system folder on 64-bit Windows. WoW64 stands for Windows 32-bit on Windows 64-bit. See: http://en.wikipedia.org/wiki/WoW64
I can't imagine how such libraries "lose" their registration unless a rogue application uninstaller (I'm looking at Inno here) trashed it. You're only lucky it didn't remove the OCX file as well.
To manually register these libraries you need an elevated command prompt and then you must run the regsvr32.exe from the SysWOW64 folder.
When developing my own ActiveX DLLs and OCXs I find the need to unregister (and sometimes register) the compiled product. Normally I'll create an initial library to use as a binary compatibility reference to define the classes and interfaces, and the first thing I do is unregister it.
In any case, it is handy to have a quick way to deal with this, so I have a few "drag and drop" scripts I use that address both issues (elevation, SysWOW64).
Here is one for registering ActiveX DLLs (including OCXs):
DLLReg.vbs
Code:'Register an ActiveX DLL or OCX.
'
'RUN THIS AS AN ADMIN USER (on Vista or later you will
'be prompted for elevation).
'
'Drag the DLL's Explorer icon onto the icon of this script,
'or execute it from a command prompt as in:
'
' DLLReg.vbs fullpathtoDLL
'
Option Explicit
Private Const ssfSYSTEMx86 = &H29
Private System, WinVer
If WScript.Arguments.Count < 1 Then
WScript.Echo "Missing DLL parameter." & vbNewLine _
& "Use DLLReg.vbs fullpathtoDLL" & vbNewLine _
& "or drag DLL's icon onto this script's icon."
Else
System = CreateObject("Shell.Application").NameSpace(ssfSYSTEMx86).Self.Path
With CreateObject("WScript.Shell")
WinVer = .RegRead("HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CurrentVersion")
If Fix(CSng(WinVer)) < 6 then
'Win2K or XP (run by admin user).
.Run """" & System & "\regsvr32"" """ & WScript.Arguments(0) & """"
Else
'Vista or later, request elevation.
With CreateObject("Shell.Application")
.ShellExecute System & "\regsvr32", """" & WScript.Arguments(0) & """", , "runas"
End With
End If
End With
End If
There is a problem with MsComCtl.ocx version 6.1.98.34.
http://answers.microsoft.com/en-us/w...dows_update/se
curity-update-for-mscomctlocx-kb2597986-ms12-060/6dadedda-7bfa-4569-91d8-a31
ebcf6a08a?page=1&tab=question&status=AllReplies
J.A. Coutts
Ahh yes, there is that too as well as those nefarious "security rollup" packages.
I'll try posting that link so it works:
Security Update for mscomctl.ocx (KB2597986 MS12-060) August 2012 Updates: Listbox double-click no longer works
It is easy to assume everyone is aware of the danger of those "updates."
I've seen you trash Inno setup a few times in this forum, and I'm curious about the reasons for that.Quote:
Originally Posted by dilettante
I've used Inno for many years, and it has worked very well for me through *most* of those years. I say "most" because early on I was very green, and I didn't have a full understanding of what I was doing, so it was easy to create an installer that could cause system problems (thankfully I was smart/lucky enough to run into these problems on my own systems instead of client systems).
However, are other installer solutions any more immune to these kinds of problems? Unless you are installing everything to the user's local appdata folder*, then all all installers that are given Admin access can really muck up any system AFAIK.
So is the problem with Inno specifically, or is that Inno is so much more accessible (being free and open source) that more "newbie" programmers make use of it (and muck it up, sometimes really badly), that is the real issue?
Anyway, I'm honestly curious and happy to be educated.
* a la chrome (at one point at least, which I recall people complaining about)
Obviously it is not depended on which installer is used, but by those who create the installation setup.Quote:
Originally Posted by jpbro
InnoSetup is very very good!
The only problems that Inno has is that it is dangerous by default, and is used by far too many people who do not know what they are doing with it.
It is an extreme example of a scripted installer. Unless you tell it to do something it doesn't do it.
This might seem reasonable on the surface, but there are a number of things that a proper installer is supposed to do. Some of the most important of those involve checks for already-installed versions of files, version checking these to see whether the existing version is newer than the version in the package, and looking for and creating or incrementing (decrementing on uninstall) "usage count" entries in the registry.
I have had many client complaints that an application I wrote "suddenly won't run." Most of these exhibit one error or another of the "can't create object" type.
In every case one or more libraries "became unregistered" and/or had been deleted from the system. And in the majority of cases the users have admitted they had just uninstalled another application before the problem occurred... and when we looked at that application's "setup" package it was created using Inno. In the rest of the cases the users are simply clueless.
And I have seem the very same thing occur on my own PCs.
So while I agree that in hypervigilant hands it might be a perfectly good packaging tool, it is hazardous by its very nature.
I completely disagree.
I use InnoSetup for years with success and satisfaction.
But, like anything else in the world, must learn to use it.
Denigrate a product just because someone does not know how to use it, it's like to denigrate a car just because someone does not know how to drive it.
From you, I would never have expected such arguments.
When I stop seeing cases where such packages break other applications I might consider revising my opinion.
The problem seems to be serious. The basic facts are:
1. It ocurred in 3 different computers, all 3 Winsows 7, 2 of them 32 bits, one 64 bits.
2. It happened the same day on all of them.
3. I got the message that the ocx was unregistered so I(successfully) proceeded to register it. Thereafter I started again the IDE but I got the message again as if the regisration had failed. And so on.
4. In one of the computers the version of mscomctl.ocx is 6.1.95.45 so it shouldn't run into the above referred problem.
See:
Security Update MS12-060 Impairs Functionality of Access Database
http://support.microsoft.com/kb/2748410
Thank you but I don't think it applies to my case.Quote:
Originally Posted by gibra
Perhaps the Inno conversation is better suited to a separate thread, since it is off-topic here, but I will just say this Dilettante - your argument against Inno sounds a lot like the arguments from "real" programmers (C, C++, etc...) against VB; that there are so many poor VB programmers and programs out there that the reputations of the whole language and anyone who uses it for development are tarnished. Of course we know that in capable hands, VB6 is a very powerful and useful language.
Will I have to make a fresh Windows 7 installation in the end?
Yet another try. I have downloaded an earlier version of mscomctl. Have unregistered the current version and then copied the downloaded file to Windows\System32 (it's 32 bit Windows 7) and registered it. Then when starting the VB IDE it hangs frozen.Quote:
Originally Posted by krtxmrtz
I used RegDLLView to make a screen shot in case it may be any of any help, although the image resolution has become degraded.
Attachment 112729
I have unistalled and then reinstalled VB6, uninstalled IE10, set the clock back to March... all to no avail. I'm getting next to desperation.
Try this fix. Run elevated (Admin) command prompt:
x64
---
cd C:\Windows\SysWOW64\
regtlib msdatsrc.tlb
x86
---
cd C:\Windows\System32\
regtlib msdatsrc.tlb
I tried on a x86 environment but it failed:Quote:
Originally Posted by DrUnicode
Attachment 112831
Look here:
http://www.vbforums.com/showthread.p...=1#post4641423
With the code shown in post #13 in the above thread, you can compile your own little regtlib or unregtlib helpers (or just use it directly per Code in the IDE).
The code also addresses a common problem which can make typelib-registering on Systems >= Vista unreliable.
Olaf
I followed the exact instructions yet to no avail.Quote:
Originally Posted by Schmidt
However, I don't know the difference between type libraries, dlls and ocx. Why do I have to register msdatsrc.tlb if the problem I'm having is with mscomctl.ocx?
Many controls allow binding to a data source. When msdatsrc.tlb becomes "unregistered", these controls will refuse to load. This apparently is what happened with the Windows 7 update which installed IE10.Quote:
Why do I have to register msdatsrc.tlb if the problem I'm having is with mscomctl.ocx?
Update: today I tried it on my laptop and it worked. However I'm still geting a similar (to that in the OP) message this time about a Tabbed dialog control: "Class TabDlg.SSTab of control SSTab1 was not a loaded control class".Quote:
Originally Posted by Me
New attempt.
On one of my desktop computers I uninstalled IE11 (current version is now 9) and the mscomctl issue became fixed. However, when I start the VB IDE I get this error warning:
Attachment 113081
Any suggestions?
Start the IDE as Admin either by manually selecting run as admin or by setting the property on the shortcut
Yes it works, thank you, but it's a nuisance if I have to do it this way every time. Isn't there some permanent fix to revert to the former state?Quote:
Originally Posted by DataMiser
I finally found this web site
https://www.fmsinc.com/MicrosoftAcce...rols/mscomctl/
which helped me fix the mscomctl issue, but I had to go through all the steps and it wasn't until the very last one that I succeeded, i.e. deleting this registry entry:
HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}
Still I'm at a loss as to what exactly triggered these catastrophic events. Was it a IE upgrade? The thing is it failed the same day on all my Windows 7 computers.
I had the same problem awhile back and remember problem occurred after I installed the IE upgrade although, so to why it happens I have no idea.Quote:
Originally Posted by krtxmrtz
As to the Tabctl32.ocx thing I reported in post #24 it isn't occurring any more, but I couldn't say what I exactly did on that computer.
One thing seems to be clear. Even if IE had something to do with it, rolling back to a version <10 is probably necessary but insufficient.Quote:
Originally Posted by Nightwalker83
Even if I haven't a clue why all this happened and an answer to post 27 is pending I'll mark the thread resolved.
check the shortcut properties, there is a checkbox there to set it to run as adminQuote:
Originally Posted by krtxmrtz
You're right, I never noticed that checkbox.
Not that I'm too happy about not understanding why I must do this in a computer but not in others but I can live with it.
Thank you.
Oops! I stated that too quickly, I've just checked in a different computer and the checkbox was clciked. I assume it was was default as I'm not aware having checked it myself.Quote:
Originally Posted by Me