ActiveX blows up IE when using cab

[amchi]

So I built an ActiveX control into ocx...
Used 'Package and Deployment Wizard" to create the cab.
The ActiveX is built using VB6

The ocx has 2 buttons and a text box.
When first button is clicked it talks to a 3rd party dll to grab input from sound card and process it.

When I fire up the page created by the 'wizard' it blows u IE as soon as I hit the first (record) button.
The error I get is something like
---------------------------------------------------------------------------|
Internet Explorer |
AppName:iexplore.exe AppVer:6.0.2900.2180 ModName: msvbvm60.dll |
---------------------------------------------------------------------------|


The code in html page only contains this (with html, head and body off course):

<OBJECT ID="eSign"
CLASSID="CLSID:185A3ED0-05B9-4585-97EC-27EC9B031532"
CODEBASE="eSign.CAB#version=1,0,0,10">
</OBJECT>

If I tell it to use

CODEBASE="eSign.OCX"

it behaves.
I accessed the test page created by wizard both through local IIS and directly by clicking on the htm page it created with same result.

I am in a corporate environment so modifying IE security settings is next to impossible.

Any idea what this might be?
Would wrong classid cause this (have no idea what classid does)?

[Hack]

The only thing the CAB file is good for is installing the component.

Once installed and properly registered, the OCX file itself is the important part, so it would make sense to tell your codebase to use that.

[amchi]

Thanks Hack...
Things are clearing up (slowly)

So, technically I could do this.
Create a cab.
Tell the page to use that.
And once I'm sure every user has what they need, change the codebase to use just ocx.
Does that make sense?

If the cab is signed will IE allow it to push files to System32 dir and register it in ..well ... registry ... ?
If it's signed will IE be able to 'talk' to ActiveX control using JavaScript ...
or will that still be considered unsafe ... and be blocked?

[Hack]

Lets get to a fundamental base of reference here.

You created an OCX control, and you need this control for clients to interact with your web site? What exactly is the purpose of this control and why would I, as a user of your web site, need it?

If you are in a corporate environment, couldn't you just ship this install out to all machines so your web site doesn't have to worry about installing it?

[amchi]

You created an OCX control, and you need this control for clients to interact with your web site?

-Yes

What exactly is the purpose of this control and why would I, as a user of your web site, need it?

The purpose is to capture sound card output.

If you are in a corporate environment, couldn't you just ship this install out to all machines so your web site doesn't have to worry about installing it?

Would love to do that.
It would take forever to find out who is in charge of such a thing (if allowed at all).
Lots of red tape.

My biggest problem is that when I deploy the control (locally or remote IIS) it just blows my IE up ...
If I fire up the ActiveX solution it opens IE window with "C:\Program Files\Microsoft Visual Studio\VB98\eSign.html" .....that only has a classid reference...and this is the only time control works.

I just realized that it works when I use classid reference instead of CAB o n l y if the ActiveX VB project is running ....

Not sure if this makes a difference ....
ClassId reference in registry for this control has an entry for InProcServer like "C:\Program Files\Microsoft Visual Studio\VB98\VB6DEBUG.DLL"

ClassId for deployed control has a InProcServer reference set to a full path to the control inside a Visual Studio project ...


Starting to hate ActiveX .....(even though it's pretty cool that I can talk to sound card and whatnot)