PDA

View Full Version : ISX Problem: Crescent OCX's not registering.



NewsArchive
12-20-1996, 01:00 AM
I figured the tdbg32.ocx problem out. It it dependent upon grdkrn32.dll to
be registered first before tdbg32.ocx can be registered. But I'm having
problems with the Crescent suite of OCX's registering. Any ideas?

NewsArchive
01-11-1997, 01:00 AM
cmsofnh wrote:
>
> I figured the tdbg32.ocx problem out. It it dependent upon grdkrn32.dll to
> be registered first before tdbg32.ocx can be registered. But I'm having
> problems with the Crescent suite of OCX's registering. Any ideas?

My only idea is that this ISX product is very shaky. I cannot get the CRYSTL16.OCX to
register. I can only share what I've done with that as I do not use Cresent:

a. The "Begin Automatic Review" button can cause problems. Clicking it the first time is
sort of useful to build an initial list in the system files group. The problem is that
the list is not complete and worse it can undo other things you may have checked. For
example, in chasing down a problem, clicking auto review again removed my check of the
ODBC item and I inadvertently delivered a setup disk without the ODBC drivers I
originally had.
b. The auto review included CRYSTL16.OCX and about 12 related DLLs but this list is
wrong for at least two reasons:
1. We need about 25 DLLs in all to support the Crystal RPT files we deliver so I
created a separate "GROUP" I called "Crystal Extras" and manually added the DLLs
Installshield omitted from the original list in the "SYSTEM GROUP".
2. Installshield violates one of their own rules by listing the CRYSTL16.OCX
before CRPE.DLL and the other Crystal DLLs. The order is apparently important. I've
learned to use QuickView to see the DLLs required by an OCX and make sure these DLLs are
listed in a group before the OCX.
c. Because CRYSTL16.OCX requires CRPE.DLL, I moved the CRYSTL16.OCX to the bottom of the
SYSTEM group under the theory that this would satisfy the "ordering rule". I've had
mixed results with this approach. In one case, this seemed to work but now I've
discovered a case on a "virgin" Win95 machine it does not register the CRYSTL16.OCX.

No error message, no log file exists; so I discover later at runtime when I click on a
command button in my app I get a message: "Can't load (or register) custom control
CRYSTL16.OCX".

I am at the point now where I am debating whether to try to upgrade to Express Pro 1.1
or shop for a install product that works well and is supported better. I've heard good
things about Wise.

NewsArchive
01-23-1997, 01:00 AM
John Adams <john.j.adams@worldnet.att.net> wrote in article
<32D7CAB7.13B3@worldnet.att.net>...
> cmsofnh wrote:
> >
> > I figured the tdbg32.ocx problem out. It it dependent upon grdkrn32.dll
to
> > be registered first before tdbg32.ocx can be registered. But I'm having
> > problems with the Crescent suite of OCX's registering. Any ideas?
>
> My only idea is that this ISX product is very shaky. I cannot get the
CRYSTL16.OCX to
> register. I can only share what I've done with that as I do not use
Cresent:
>
> a. The "Begin Automatic Review" button can cause problems. Clicking it
the first time is
> sort of useful to build an initial list in the system files group. The
problem is that
> the list is not complete and worse it can undo other things you may have
checked. For
> example, in chasing down a problem, clicking auto review again removed my
check of the
> ODBC item and I inadvertently delivered a setup disk without the ODBC
drivers I
> originally had.
> b. The auto review included CRYSTL16.OCX and about 12 related DLLs but
this list is
> wrong for at least two reasons:
> 1. We need about 25 DLLs in all to support the Crystal RPT files we
deliver so I
> created a separate "GROUP" I called "Crystal Extras" and manually added
the DLLs
> Installshield omitted from the original list in the "SYSTEM GROUP".
> 2. Installshield violates one of their own rules by listing the
CRYSTL16.OCX
> before CRPE.DLL and the other Crystal DLLs. The order is apparently
important. I've
> learned to use QuickView to see the DLLs required by an OCX and make sure
these DLLs are
> listed in a group before the OCX.
> c. Because CRYSTL16.OCX requires CRPE.DLL, I moved the CRYSTL16.OCX to
the bottom of the
> SYSTEM group under the theory that this would satisfy the "ordering
rule". I've had
> mixed results with this approach. In one case, this seemed to work but
now I've
> discovered a case on a "virgin" Win95 machine it does not register the
CRYSTL16.OCX.
>
> No error message, no log file exists; so I discover later at runtime when
I click on a
> command button in my app I get a message: "Can't load (or register)
custom control
> CRYSTL16.OCX".
>
> I am at the point now where I am debating whether to try to upgrade to
Express Pro 1.1
> or shop for a install product that works well and is supported better.
I've heard good
> things about Wise.
>
I have experience with distributing Crystal Reports for a VB4 application,
and will say that it is the worst. As stated in another ISEP newsgroup,
Crystal Reports upgraded DLLs without updating their internal version
numbers (stupid!!!). I could list other issues I had with Crystal Reports,
but it's not worth it. I would not use problems with Crystal Reports as an
example.

DH