I know, there are countless threads about this control already and I've been reading them for hours. I can't add get this ocx to load into VB6, running 64 bit Win 7.
Things I have already tried:
1. unregistering and re-registering (used regsvr32 from syswow64)
2. Did the regtlib msdatsrc.tlb thing I've found
3. Reinstalled sp6
4. Installed the cumulative update everyone is saying is the latest version
I haven't reinstalled VB6, I don't have the media at work or I would have, but this has shown to never be the solution to this problem on the successful fixes I've read about these past few days I've been working on this.
Things to note that people aren't talking about in the other threads: I can add the ocx to Office without issue, then add controls (treeview, imagelist, etc) and use them fine. I can't add the OCX to a new, empty VB6 project. Most users are trying to open existing project, which fails for me as well, but never say whether they can add the OCX to a new project. I can't.
I hate to create another one of these threads to further muddy the water, but the solutions in other threads haven't been working for me and no one is mentioning where they can add it to Office or a new project.
This used to work fine months ago, too many things have happened since then to be able to pinpoint one that may have caused this. My main focus is to be able to add it to a new project again.
Thanks.
EDIT:
VB is being run in elevated XP SP3 compatibility mode.
Found the solution. I don't know how it came to be, but I had 3 different versions registered in my registry. Maybe the version that was trying to be used by VB wasn't compatible but was compatible with Office? I don't know.
Here's what I did.
I opened up the registry (regedit.exe) and searched for the key 831FDD16-0C5C-11D2-A9FC-0000F8754DA1 and found the three different versions were listed. I made a backup of the sections I was going to change, of course, and then just deleted all of the version entries. After that, I went back and registered what I had in my syswow64 directory and now it's back to normal. Rechecking the registry shows I now only have version 2.2 installed.
Related
This may be trip down memory lane. I have been asked to fix some code that was written 8 years ago. That in itself is OK. I have a Win 7 64 bit PC. As I now use VS2012 I had to install 2005 luckily had a copy still. Then all the updates from MS so that it will work with Win 7 64 bit. Create a dummy MFC app to make sure it all works. So far so good. Next I get the SDK to target the code to it is running on a Moxa UC7124 ARM4i. I get UC712XCE_SDK_V2.0.msi and install it.
Now the problem starts. I cannot see the Moxa platform inside VS2005. If I load the solution it comes up with the platform but skips compile. My guess is that VS cannot find the SDK. I have tried many things but obviously not the correct thing yet, I checked for environment variables and find none, registry has no entries.
I look inside Tools | Options under Projects and Solutions VC++ directories but cannot find the platform I only get Win32. So for the first time in a while at the moment I am lost. Has anyone got any ideas why I cannot get the Moxa SDK visible inside VS2005?
After several days progress has been made ....... but not yet fully working. My view was that there must be some permissions issue in Win 7 when trying to load older SDK's, so I uninstalled the SDK first. Next I right click on the SDK's msi and in security tick "run as compatibility" and choose "Previous version of Windows". I can now target my solution correctly. So this part appears to be working now and next I have to fix all the compile/linking issues. Still got a big hill to climb but fingers crossed when I get to deploy this that it is all going to work OK.
I got a weird problem with my VB app that has got me very confused. I am updating an existing program. I had to add some processing queue capabilities. On my system, unit testing worked great but when I compile it and run it on a different computer (a network server machine) it first tries to open an office install. If I cancel this, the program seems to run fine. The problem is that this program will be run in the background and I can't be hitting cancel each time it runs.
So my question is this: what is going on here? I'm usually a java developer we eclipse so I'm used to being able to include all the needed libs into the jar files automatically. It doesn't seem like the case with VB6. it seems like it expects all the same libs to be on all the systems. Is there any way to tell what might be triggering this?
The only thing I can think of that is causing it is that I'm using the "OpenProcess" function in the kernal32 lib. that the only major change I have made.
any help would be very appricated. thanks!
EDIT:
It seems that multiple versions of word were installed on the system and it was screwing things up somehow. We uninstalled one and it fixed it.
I ran into this a while ago and it was related to my installer for the VB6 app overwriting some system files for Office that it shouldn't have. Any time one of the System dlls was accessed Windows would determine that something was wrong and the Office installer would start up.
The short-term fix was to let the Office Installer repair the broken chain of dlls.
The long-term fix was to never overwrite built-in Windows System dlls.
You could also check out the Microsoft Fix it Center.
I'm trying to deploy some Vb6 components on a Windows Server 2003 Standard x64 R2. I normally run these in a com+ application and I went through the normal routine of creating the COM+ application and adding all the components. Everything seemed to work fine until I actually tried to use any of the components. I would some kind of "ActiveX component can't create object" or "Application-defined or object-defined error" or something similar to that.
To remove as many variables a possible I created a very simple VB form to consume the simpliest of the components and tried that. Nope. So I created a simple install to install the component, and whooo hoooo it worked. So I tried one of the more envolved components with high hopes ... but no after the install I still can't call the component successfully. Using Dependency Walker I discovered that for some reason the msvbvm60.dll is not properly registerd.
I've downloaded VBRUN60.exe and VBRUN60SP6.exe and tried installing them. Even going so far as to do a run as with the administrator account and removing the check box for "Run this program with restricted access". I've tried to manually register the msvbvm60.dll in the SysWow64 directory.
Nothing seems to work. It just won't register. Does anybody have any suggestions? At this point I'll try just about anything.
Thanks
If you are registering the components manually you need to pay extra attention. As you are on a 64-bit OS there are two versions of regsvr32.exe. When registering VB6 components you must make sure to use the 32-bit version of regsvr32, which is located under the following location:
%WINDIR%\SysWOW64\regsvr32.exe
If you just type regsvr32 on the command prompt, normally the 64-bit version is chosen (because %WINDIR%\system32 is contained in the %PATH% environment variable), so please make sure to use the full path as above.
If you are using a 32-bit MSI to install your components, this version will be selected automatically and the registration should work just fine.
In case you haven't already done, you should give a try to Process Monitor - one of the best tools I have used on dll registering problems.
The following links will provide some usufull clues:
An excelent tutorial on using Process Monitor for problem solving;
ActiveX component can't create an object
RESOLVED! ActiveX Component Can't Create Object: Cube build failure against SQL Server 2005 Analysis Services
Hope it helps :D
I've had trouble with unregistered components for Visual Basic 6 - although not tried to use the same one as you are mentioning. Manually registering never resolved things, no matter which reg server was used
The problem (eventually) turns out to be Internet Explorer 10. Uninstalling that (due to the way Windows 7 handles IE as Windows updates, this meant unistalling newer versions first to expose the older ones) worked. Afterwards, reinstalling the latest IE brings no problem.
Bit of a random one here, and I've exhausted my knowledge on how to try and remedy this.
Basically I've just switched out my hard-drive over to an SSD (best move I ever did), and along with this I've had to reinstall everything from the ground up. When I've done so however VS2010 Express for Windows Phone keeps giving me this error with my existing projects(Silverlight 4 SDK is not installed + bunch of warnings).
But I have made sure it is installed
I have gone through reinstalling the Silverlight 4 SDK, uninstalling all of Silverlight + VS (and all it's many, many components in Control Panel) and performed updates via Windows Update, rebooting etc. Nothing seems to work.
Strange thing is though, if I create a new project it works just fine, no warnings, no errors, nothing. I'm completely stumped.
Any ideas guys?
My usual install process is:
Silverlight SDK > VS2010 Express for WP7 > Begin Developing
I have deleted the .suo/.user files, also the obj and Bin directories too. No avail :(
The only thing really that has changed since my last install was the directory I am loading the actual projects from (but I don't see how this could affect it?).
I wasn't able to solve this one without performing a full reinstall. I did discover some other elements of Win32 applications having issues as well, seems my Windows install was simply broken.
it starts up windows installer with random applications on my machine . . after i click cancel a few times, it loads vb6 fine.
any ideas why this is happening?
To stop this behavior:
Start VB6
Open the Add-Ins dialog
Uncheck the "Visual Component Manager" Add-In
Source:
After VS2010, SP1, VB6 launches VS2010 installer
This is what a Windows Installer repair looks like. It means that something is broken in one of the installed products on your system. Ideally it's a one-off repair so you might be better off letting it runs its course and do the repair, except of course if it asks for a install CD that you don't have.
The Windows event log (Application) will have MsiInstaller entries saying what product and component has the problem.
It's possible a previous installation has not completed correctly.
Use the utility at the following link to remove any rogue installations files:
http://support.microsoft.com/kb/290301 (broken link Aug.2017, leaving URL for "historical purposes").
As PhilDW has pointed out this is a Windows Installer Self-Repair issue, and can often be resolved by allowing the self-repair to complete once. At other times the problem persists and it should be fixed by other means. Even when the self-repair completes and the problem goes away, it can still resurface once you launch the conflicting application. Windows Installer is not easy to deal with.
In your particular case you might be able to get away with a "workaround" rather than a fix. By locating the main VB6 EXE file on disk (in its main installation directory) and manually creating a shortcut to it on your desktop, you might be able to successfully launch VB6 via this new shortcut without the self-repair kicking in. It might be worth a try.
This shortcut trick will not remove the underlying problem, but might help to "bypass it". Just for the record: the reason this might work is that the new, manually created shortcut is not "advertised" and will not trigger a key-path check of the installed product when launched. This is Windows Installer's way to verify that a product is correctly installed. Note that even if the workaround works, self-repair might still result during application use because of faulty COM data being detected (which is very likely the cause of the whole problem you are seeing, but give the manually created shortcut a try).
There is a rather comprehensive "article" on self-repair here: How can I determine what causes repeated Windows Installer self-repair? which might help to track down the cause of the self-repair kicking off in the first place, but fixing it can be a rather complicated process (so try the workaround first). It is a long article because there are so many different ways self-repair can occur. The common denominator is that different installers on your system are fighting over a shared setting that they keep updating with their own values on each application launch in an endless loop. The last application to launch will overwrite the registry or file system with its own setting.
This worked for me, for VS2010 RC:
"Please wait while windows configures Microsoft Visual studio 2010 Ultimate."
THe work around that fixes the issue for me was to run the following via the admin cmd prompt.
Md "%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\common7\IDE\FromGAC"
from http://social.msdn.microsoft.com/Forums/en-SG/vsprereleaseannouncements/thread/572a0f8a-16b0-4e1d-b581-16be36a9b564
This was also happned to me.
Whenever i tried to open vb6, it started windows installer to configure "Autocad".
Autocad had not broken. and it was working fine.
I tried removing and reinstalling Windows Installer, But it did not solved the issue.
Then i installed Microsoft's "Windows Installer Clean Up Utility 2" from given link.
Using this utility i removed the autocad from "Windows Installers" Database.
After that VB6 never started installer again.
Keep in mind 'removing any entry from installer's database may be risky, but i had no choice. So do it on your own risk.
Download "Windows Installer Clean Up Utility 2" (this is a deprecated, unsupported and unsafe tool to use - Aug.2017. I will leave the link in for "historical purposes", don't use it).