Safe to make this CLSID change now?

[AndyGroom]

thread222-1525582

The fixes in this post were designed as a fix to try when the WebBrowser control wasn't working, I'm seeing the same problem quite often in Windows 7 and 8 and this seems to fix it. (It doesn't happen on every Windows 8 machine though, which is strange).

Is there any reason why my application shouldn't make the changes during installation? Would they stop other applications from working correctly?

- Andy
___________________________________________________________________
If a man speaks in a forest and there are no women around to hear him - will he still be wrong?

 

[dilettante]

Your application has no business touching those registry entries under any circumstances.

Just fix your program. If that registry hack makes it work you have a problem to resolve. My guess is that it was compiled on a system where somebody else went a-hacking-we-will-go on those IE registry keys.

I just tested it. A program properly referencing shdocvw.dll (Microsoft Internet Controls) works fine here on Windows 7 SP1, Windows Vista SP2, Windows XP SP3, and even Windows 95 OSR2 without recompiling.

 

[AndyGroom]

It was compiled on an XP machine with IE 8 installed (if that makes any difference) and on which I haven't purposefully edited any key registry entries to work around a problem. Is the solution to recompile my application having first changed the way in which the webbrowser controls are referenced - if so how do I do that?

- Andy
___________________________________________________________________
If a man speaks in a forest and there are no women around to hear him - will he still be wrong?

 

[dilettante]

Your problem is XP. This is an unsupported and unsafe OS and shouldn't be used at all, but even much less for software development. I'm not sure the platform was ever updated to fully support the changes made to IE starting in IE7.

But let's just ignore that reality for the moment.


It sounds like this PC has gone for a long time without a fresh installation of Windows XP, so you may have all sorts of built up crud. In this case the crud could be an obsolete VB6 type library cache ("object cache") file, probably named something like [tt]shdocvw.oca[/tt] or [tt]ieframe.oca[/tt] and probably located within [tt]C:\Program Files\Microsoft Visual Studio\VB98[/tt].

You can remove that, or if feeling paranoid rename it.

Next create a backup copy of project folders you will work on.

Then (assuming you have IE7 or IE8 installed) you will probably have to open your broken projects one by one, remove instances of the WebBrowser control from every Form or UserControl, remove the broken reference to Microsoft Internet Controls, and save. Then close the IDE and re-open each project to re-add the new correct reference to Microsoft Internet Controls and re-add instances of the WebBrowser control. Then save and recompile.

A slightly easier fix might be to just replace the bad references in the files making up each project. The correct line in .VBP files look like:

Object={EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}#1.1#0; ieframe.dll

In .FRM files (and probably in .CTL files too) it looks like:

Object = "{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}#1.1#0"; "ieframe.dll"

But verify that typelib GUID first by looking for it under [tt]HKCR\TypeLib[/tt] in the registry. Since it doesn't vary, this is just for your own comfort. Lots of people make claims this doesn't work but I suspect they try to do it changing only the .VBP file's reference.


Time to dump Windows XP.

 

[AndyGroom]

Thanks, I will try all that.

If it's of any relevance, I created a new project with just a webbrowser control on a form set to open the Google homepage, compiled it and sent it to our client and that works fine.

- Andy
___________________________________________________________________
If a man speaks in a forest and there are no women around to hear him - will he still be wrong?

 

[AndyGroom]

In my .VBP file I've changed

Object={EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}#1.1#0; shdocvw.dll

to

Object={EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}#1.1#0; ieframe.dll

but as soon as I alter and save the project it goes back to shdocvw.dll again.



- Andy
___________________________________________________________________
If a man speaks in a forest and there are no women around to hear him - will he still be wrong?

 

[dilettante]

The IDE will look up the typelib GUID and update the [tt]Object=[/tt] lines in the soruce files. Type libraries are only used at compile time anyway, with very rare exceptions (usually software development tools making use of TlbInf32.dll).

I don't think you have described your actual problem in enough detail for anyone to help. The trouble probably lies elsewhere.

If it's of any relevance, I created a new project with just a webbrowser control on a form set to open the Google homepage, compiled it and sent it to our client and that works fine.

Sounds relevant to me.

 

[AndyGroom]

I don't think you have described your actual problem in enough detail for anyone to help

Yes you are probably right. Our VB6 application running on *some* Windows 8 machines shows just an empty white space wherever a WebBrowser object should appear. You can't interact with the white space in any way. However as mentioned above if we compile a simple test application on the same development machine showing just a WebBrowser object on a form it appears as you would expect on the same Windows 8 machine. On other Windows 8 machines both applications run correctly and the WebBrowser object appears. This is also the case on one Windows 8.1 machine (it appears correctly). I don't know whether the problem lies with a setting on the local W8 machine or within the VB6 application.

- Andy
___________________________________________________________________
If a man speaks in a forest and there are no women around to hear him - will he still be wrong?