PDA

View Full Version : IS X not "Seeing" my OCX files when scanning



pjme7154
08-31-2004, 12:06 PM
Hi,

I've written some custom activeX controls that I use in other VB6 applications. Every time I create a new install package, I let IS scan the VB project for dependencies.

It is always able to see the .ocx file that it needs to include in the package, however, it never seems to know its location and displays "*** missing file ***" in the dependency list. As a result, I cannot "check" it to include it in the package (I always need to add it manually).

These activeX components are registered on the source machine, so I can't understand why IS cannot see where they are located. Any ideas?

Much thanks!
-PJ

Mike Marino
09-09-2004, 06:11 PM
Are these OCX's listed in the Visual Basic Project File, if they are, we should find them.

If these files are being picked up as static dependencies we are probably only looking through the standard search path. So if the OCXs are not in the same folder as the Application, Windows Folder, or System 32 they may be missed.

Hope this helps.

pjme7154
09-09-2004, 06:22 PM
They are in fact referenced in the VB project. When a dependency scan is conducted, they do show up in the list of required dependencies, however, ISX is unable to determine their location on my development machine. They are registered locally on the system. Is this enough to do they need to be added to the search path for dependency files (within ISX)?

Mike Marino
09-09-2004, 06:25 PM
I would think that would be enough. But it has been a while since I looked through that code, so I could be wrong.

Adding it to the search path should fix the problem. I will do some tests on my side to see if I can locate the bug.

Thanks.

Mike Marino
09-09-2004, 08:35 PM
OK I did a quick test. First I created a VB OCX at the following location:

C:\Documents and Settings\MichaelMarino\My Documents\Test\Project1.ocx

Then I created a VB EXE that used the ocx at:

C:\Documents and Settings\MichaelMarino\Desktop\VBTest\vb6projectProject1.exe

Note neither are on the standard search path.

Next I created an Express Project using the VB wizard and scanned:

C:\Documents and Settings\MichaelMarino\Desktop\VBTest\vb6projectProject1.vbp

Which looks like:

Type=Exe
Form=Form1.frm
Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#..\..\..\..\WINDOWS\System32\STDOLE2.TLB#OLE Automation
Object={A85DE433-450A-4C63-BCC0-E4030CDC4702}#1.0#0; Project1.ocx
Startup="Form1"
....

The important part is that the ocx is only reference by classid.

The Express VB Scanner did pick up the dependency in the correct location.

However if I unregistered Project1.ocx, Express reported the file as missing.

This is functioning as I would expect. Can you try to re-register the files Express thought were missing and try the scan again?

Thanks.

pjme7154
09-10-2004, 12:13 PM
I re-registered both of the custom OCX's and ran the VB import wizard again. Interesting, it is able to pick up the location of the GranRIO32 control, but not the GranBEC. This is repeatable, and the controls are definitely registered on the system.

Object={0891AEAF-4646-4043-A7C9-695ED74F9711}#84.0#0; GranBEC.ocx
Object={A1414EA5-6935-4151-8D0B-51057E8DECD3}#1.0#0; GranRio32.ocx

My applications run fine with this control, so the system knows where it's located, but ISX is unable to determine this. Not sure why!

Cheers

Mike Marino
09-10-2004, 12:55 PM
Can you send me the project and OCXs, I would like to investigate this further.

Thanks.

mmarino@macrovision.com

Mike Marino
09-13-2004, 05:13 PM
Here is what we have found upon looking closer at the DLLs in question:

It appears to be a problem with the Typelibrary in the OCX itself.

Visual Basic thinks the version number for the Typelibrary of the OCX is:

84.0

You can see this in the VBP:

Object={0891AEAF-4646-4043-A7C9-695ED74F9711}#84.0#0; GranBEC.ocx

However the OCX registers itself as version 54.0 -- here is a copy of the Registry Entries it makes:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\TypeLib\{0891AEAF-4646-4043-A7C9-695ED74F9711}]

[HKEY_CLASSES_ROOT\TypeLib\{0891AEAF-4646-4043-A7C9-695ED74F9711}\54.0]
@="GranBEC"

[HKEY_CLASSES_ROOT\TypeLib\{0891AEAF-4646-4043-A7C9-695ED74F9711}\54.0\0]

[HKEY_CLASSES_ROOT\TypeLib\{0891AEAF-4646-4043-A7C9-695ED74F9711}\54.0\0\win32]
@="C:\\Documents and Settings\\ReleaseEngineer\\Desktop\\New Folder\\New Folder\\GranBEC.ocx"

[HKEY_CLASSES_ROOT\TypeLib\{0891AEAF-4646-4043-A7C9-695ED74F9711}\54.0\FLAGS]
@="2"

[HKEY_CLASSES_ROOT\TypeLib\{0891AEAF-4646-4043-A7C9-695ED74F9711}\54.0\HELPDIR]
@="C:\\Documents and Settings\\ReleaseEngineer\\Desktop\\New Folder\\New Folder"

Our VB Scanner looks for the Exact version of the Typelibrary -- in case multiple version exist.

Is this an OCX you purchased, or is it internal to your company? I am going to look at making our VB scanner a little more flexible when it comes to Typelibrary versions not matching.

Hope this helps,
Mike Marino

Mike Marino
09-13-2004, 07:46 PM
The plot thinkens....84 is 54 hex so my guess is that our VBP reader is not doing a Hex conversion before reading the registry.

So this looks like a bug on our side.

I will be fixing this in the next few hours. I will send you a DLL to try to see if it fixes the problem.

Thanks,
Mike