'No such interface supported' error in VB6.0, what to do?
sl...@my-dejanews.com
Hello!
I've just installed VB 6.0 on my Windows NT 4.0sp3 machine. Unfortunatley it
proved quite unusable. When I try to add OCX files to a project I get the
following error message:
"System Error &H80004002 (-2147467262). No such interface supported."
It pops up then I select Components... from the Project menu. After clicking
OK the normal Components dialog box appears but it's empty. None of the OCX
files installed are listed.
If I try loading one of my old projects from VB 5.0 the same error appears
when it tries to load the included OCX files.
Does anyone have a clue on whats gone wrong? I guess there's some broken
ActiveX/COM/OLE DLLs hiding somewhere in my system directory but what should I
look for? Reinstalling VB6.0 didn't help.
Regards,
Fredrik Ohrn
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
VBDis
Im Artikel <6vj90a$t04$1...@nnrp1.dejanews.com>, sl...@my-dejanews.com schreibt:
>Does anyone have a clue on whats gone wrong?
Perhaps the old OCX files were deleted, and the new ones didn't install
properly - even the files are missing, or the registration. If the files are
present, usually a double click on the OCX file will force it to register,
since almost all controls are of type "OLEselfRegister".
In addition, have a look at the VBP files with an ordinary editor. There the
absolute path (why???) of the controls is stored, together with the GUID.
Removing the path from the file name sometimes helps...
DoDi
sl...@my-dejanews.com
I'm responding to my own question since I found a solution while browsing Deja
News.
I replaced the existing comcat.dll (version 5.0) in the system directory with
the one found on the CD (version 4.2) rebooted and ran 'regsvr32 comcat.dll'.
This solved it and VB 6.0 works.
An interesting obervation is that I tried installing it on a Windows 95
machine and there VB worked flawlessly having the same v5.0 comcat.dll that
didn't work with NT. I guess abeit it says "Microsoft(R) Windows NT(R)
Operating System" in the properties box of the dll it only works with Windows
95.
I wish Microsoft would do some quality testing and assurance of their software
once in a while.
Regards,
Fredrik Ohrn
In article <6vj90a$t04$1...@nnrp1.dejanews.com>,
sl...@my-dejanews.com wrote:
>
>
> Hello!
>
> I've just installed VB 6.0 on my Windows NT 4.0sp3 machine. Unfortunatley it
> proved quite unusable. When I try to add OCX files to a project I get the
> following error message:
>
> "System Error &H80004002 (-2147467262). No such interface supported."
>
> It pops up then I select Components... from the Project menu. After clicking
> OK the normal Components dialog box appears but it's empty. None of the OCX
> files installed are listed.
>
> If I try loading one of my old projects from VB 5.0 the same error appears
> when it tries to load the included OCX files.
>
> Does anyone have a clue on whats gone wrong? I guess there's some broken
> ActiveX/COM/OLE DLLs hiding somewhere in my system directory but what should I
> look for? Reinstalling VB6.0 didn't help.
>
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
jam...@io.com
sl...@my-dejanews.com wrote:
> I'm responding to my own question since I found a solution while browsing Deja
> News.
>
> I replaced the existing comcat.dll (version 5.0) in the system directory with
> the one found on the CD (version 4.2) rebooted and ran 'regsvr32 comcat.dll'.
> This solved it and VB 6.0 works.
>
> An interesting obervation is that I tried installing it on a Windows 95
> machine and there VB worked flawlessly having the same v5.0 comcat.dll that
> didn't work with NT. I guess abeit it says "Microsoft(R) Windows NT(R)
> Operating System" in the properties box of the dll it only works with Windows
> 95.
>
> I wish Microsoft would do some quality testing and assurance of their software
> once in a while.
>
Thanks for you message -- I was encountering the same problem with VB5 and a
project where I use the MSFlexGrid control. I had just installed VJ++6, and I
noticed it updated msflxgrd.ocx -- I thought file upgrade was the problem so I
replaced msflxgrd.ocx with the VB5 version, but I continued getting the above
error when opening my project. Replacing comcat.dll with the version from the
VB5 CD worked. I sure hope this is one of the bugs MS is fixing with Visual
Studio 6 SP1 that is due out this month!
Even weirder, downgrading comcat.dll also fixed a completely unrelated problem
with my shell. I have the IE4 desktop update and had the handy Address bar on
the bottom of my screen next to the system tray. It seemed to disappear after
VJ++6 and the Address and the Links toolbars were no longer available in the
(right-click)->Toolbars menu (just Desktop, Quick Launch, and New Toolbar).
After replacing comcat.dll the Address and Links menu items reappeared, so I
was able to get back the Address bar. How the heck did the new comcat.dll
break that?
<rant>This is ridiculous -- Microsoft can't blame any third-party developers
for this DLL fiasco -- they are in control of the OS, those DLLs, and I only
installed MS apps. I wish news organizations would cover these kinds of bugs
instead of some silly JavaScript security bugs exposing my browser history --
maybe we'd get fixes faster.</rant>
PS: is anyone else noticing that articles posted to Microsoft newsgroups via
DejaNews don't seem to appear on msnews.microsoft.com?
PS2: I don't know of an easy way to replace in-use system DLLs. I wrote the
below VC++5 program to do it.
Jamshid afshar
jam...@io.com
// repdll.cpp: replaces in-use system DLLs on the next reboot.
// Handy for downgrading Microsoft DLLs where the new version (like the
// VJ++6 comcat.dll) breaks your system. Compile with VC++5
// cl /GX repdll.cpp
// Jamshid Afshar <jam...@io.com>
//
#include <iostream>
#include <string>
#include <windows.h>
int main (int argc, char** argv) { if (argc<2) { std::cout << "Usage:
repdll <dllname.dll>\nMoves the given DLL from the current directory into
C:/WINNT/SYSTEM32 upon next reboot." << std::endl; exit(1); }
std::string dst = "C:/winnt/system32/"; dst += argv[1]; std::cout <<
"MoveFileEx to " << dst << " result: " << MoveFileEx( argv[1], dst.c_str(),
MOVEFILE_DELAY_UNTIL_REBOOT|MOVEFILE_REPLACE_EXISTING ) << std::endl; return
0; }