• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2681
  • Last Modified:

Sheridan control will not register (SSCALA32)

We are creating an InstallShield Express installation for a VB5 project which includes several ActiveX controls including Microsoft FlexGrid, Tabbed Dialog, Sheridan Month/Day/Year Combo (v 1.0), and Sheridan DataGrid (v 3.0).

All except the Sheridan Month/Day/Year (SSCALA32.OCX) will register. This one OCX will not register itself during installation, nor will regsvr32 work. We do have it registered on our development machines, but we have so much other software on them that they are not good test platforms for installations. For installation testing, we use freshly installed machines, which have NT4.0 SP3, Office 97 SR2, Lotus Notes 4.5.2, Visio Standard 5.0b, IE4 SP1. This is a standard configuration for the office, and this application will be the only other thing the target machines will receive.

Other things to note:
- Registration fails with error 7E.
- We have checked the required versions of dependent system DLLs in the Sheridan list, and all the DLLs on our base systems are at or above this level.
- MSVCRT40.DLL is version 4.20, which is new to me, but is not listed in the Sheridan dependencies.
- The exact version of SSCALA32.OCX is 1.0.007

This has been a real brain twister.
0
tomook
Asked:
tomook
1 Solution
 
mcixCommented:
Did you try regocx32?
0
 
tomookAuthor Commented:
I tried calling DLLRegisterServer directly, but I have never seen anything called regocx32. What is it?

By the way, I got this to work, but I will still award points if anyone can explain why. Please do not answer unless you REALLY know. I made this component the very last thing which gets registered, rather than somewhere in the middle. This product has no dependence on other ActiveX components (at least not documented), and registering the ActiveX components does not happen until the very last thing.
0
 
kacklehornCommented:
The setup wizard is a complicated utility to explain. It DOES matter what order the files get installed in, which is why Microsoft will not support any other third party setup wizards. The reason being that the OCX, and DLL order must be precise. If one ocx requires that a certain dll be registered to create the entry point in the registry for it, and it hasn't been installed yet..you'll error out. You can check all of the dependencies for your dlls and ocxs with a keen little utility called depends.exe. You can get it from ftp.microsoft.com/transfer/outgoing/developr.

L8tor
KaCkLeHoRn
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
mcixCommented:
On the VB CD, there is a directory called TOOLS\PSS.

You will find regocx32.exe there.  

It does not seem like that is your problem though.
0
 
tomookAuthor Commented:
>> The reason being that the OCX, and DLL order must be precise. If one ocx requires that a certain dll be registered to create the entry point in the registry for it, and it hasn't been installed yet..you'll error out.

It does not appear to be the case here.

>>You can check all of the dependencies for your dlls and ocxs with a keen little utility called depends.exe.
I have it an I used it. There are no dependencies. Why should the order matter if there are no dependencies?
0
 
MirkwoodCommented:
The reason is that you can only see static loaded dependecies. i.e. dll's that are loaded when the OCX is loaded. What you cannot see is the dynamically loaded DLL. E.g. when you create an object or control this is done using COM. That means that the DLL name is retrieved of the registry and loaded dynamically.
Search on the web for a utilty called Filemon or NTFilemon (www.ntinternals.com). This shows you the files that are accessed by the OCX. This way you can find which DLLs you need to install before installing the OCX.
0
 
tomookAuthor Commented:
Good tip, Mirkwood. I will look for these utilities and let you know what happens. On thing strikes me, though. All the regular DLLs are installed before any ActiveX components. At least, that is what is supposed to be happening! I should probably check that out as well.
0
 
tomookAuthor Commented:
Got it. Thanks for the assist. Too many pesky versions of the same DLL around.
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now