Problems converting components from BCB 1 to BCB 3

OK, I tried what I thought would be simple - converting components from
BCB1 to BCB3. After several days of effort, I became completely

I finally found a strategy that works. But look at what strategies I had
to try to get there... (these are documented at

I have a library of 50 or so components. Some of them inherit from
others. Some of them use others as part of an aggregate. One is based on
an ActiveX control. As the migration of these components progressed, it
became clear that there was sonething wrong with my initial strategy to
convert each component to a separate package. Here's what I tried and
what happened...

Strategy 1:

Follow the book. Add "PACKAGE" to class and Register() declarations. Add
"#pragma package (smart_init)" to every component .cpp. Create a package
for every component using the Install Component dialog, and add the
component; use a good description of the component for improved
documentation. Combine the packages into a project group for
documentation and access purposes.

Result of Strategy 1:

Random Invalid Page Faults in the run time library CP3240MT.dll when a
component is being installed. Some components install correctly.
Deinstalling all of my component packages and then reinstalling the
problem package goes fine - the abort then shows up on the installation
of some other package. This suggests that the problem is not in the
specific package, but is probably a C++ Builder bug or an operating
system issue.

Strategy 2:

Use Strategy 1, but change the description of the components to be
shorter - in fact, to the name of the class. This makes it easier to
keep track of which components have been loaded and which haven't, to
make absolutely sure there is no problem that can be isolated to a
specific component. Also, some systems have problems with long strings
in certain contexts - perhaps this is one.

Result of Strategy 2:

Now I get an error message on the component installation which states
that one component package includes something already in another
installed component package and that therefore I won't be allowed to
install it (very suggestive that the previous aborts were caused by a
reaction to the length of the package description). Inspection of the
"requires" for the package shows it contains a reference to the
specified .bpi (which it needs, but the message says take it out). I
remove that reference. I build the package. The build tells me I need
the reference I already removed from the requires. I tell it not to add
the reference. I try to install the package. The IDE then claims the
package still contains the reference that was removed. I check the
package. The reference is definitely not there. I delete the compiler
and linker output files and build again. The IDE still claims that the
package to be installed contains the reference. But the only thing in
the package is the include file for the absolutely necessary headers.

Strategy 3:

Make a single package containing all of the component units. Build the
package and install it. Accept the things it wants to add to "Requires".

Result of Strategy 3:

It works. The package can be installed, the components show up on the

Conclusion (?)

There is some sort of bug in the handling of a) large number of separate
component packages (i.e. > 20) and b) long descriptions for component
packages. There is also a bug in the way the IDE is dealing with
intercomponent / interpackage references, which includes a) not
resolving duplicate .bpi imports in some contexts (it is not clear to me
what those contexts are, since clearly all component packages probably
reference VCL packages, and yet there is no problem with that
duplication) and b) believing those .bpi imports are present when they
have been removed (possibly based on the presence of an include in the
component source header file).

None of these restrictions is documented. The documentation seems to
clearly indicate that each package should contain a component and that
any other organization is the exception rather than the rule (see the
help file on "Components,Converting components from CBuilder 1.0").

But there is an upside. Strategy 3 compiles and makes much faster than
any of the others when you need to remake all of your components. A 20
member program group takes over a half hour to rebuild or remake, even
when the average compile is around 20 secs. The strategy 3 package takes
only a fraction of that time.


I don't understand why the other strategies didn't work. There seems to
be nothing documented that can account for the failure of those
strategies to work. In fact, it is implied in the documentation that
they are the correct strategies to use. It can't be that interpackage
references aren't allowed. So what is it?

Does anyone have any ideas?  

Mark Cashman, creator of The Temp{*word*203}Doorway at
- Original digital art, writing, and more -
C++ Builder / JBuilder Tips and The C++ Builder Programmer's Webring
(Join us!)