🚀 go-pugleaf

Alain M. Dube wrote:

> A number of "sample" vcl controls/components that I've used
> extensively in BCB6 are no longer available in C++Builder2006, for
> example, TrayIcon, CSpinButton, CSpinEdit and CCalendar.
> 
> Are there 2006 equivalents to these?  I am unable to load my projects
> in 2006 without it catching on the missing VCL items.

Quick history lesson:
Most of those samples started life as example controls written in
Delphi, to teach the art of component writing.

When BCB was created these samples were 'transliterated' to BCB -
written in C++ syntax but in a Delphi style.  It was later discovered
that as they had the same names, it was not possible to use the Delphi
and C++ controls in the same project.  So the following version of BCB
added the 'C' prefix.

Later, some examples were written purely for BCB, such as TTrayIcon.
Naturally, the Delphi customers wanted this control too, so it is now a
supported part of the VCL and not a sample at all.

Finally we come to BCB2006 where C++/Delphi are finally in synch.  The
controls without the prefix are now part of the supported VCL, and the
TC version should still be available as a sample for C++ customers
backwards compatibility.  If you can't find them I would take a look
around your installation to see if there is a project for you to build
and install.

> Also, can 3rd-party VCL components for BCB6 be used asis in 2006?
> Some of these components are very expensive.

That depends on whether they came with source code.
If you have source, there is a very good chance you can just recompile
them in the new IDE and they will install.  There MAY be a little
'porting' to do, as we are effectively jumping from VCL6 to VCL10, and
some things may have changed.  This will be equivalent of finding any
issues in your own code too.

If you don't have source, you are entirely dependent on your tool
vendor.  That is why we will never use controls without source in our
production systems.  It is not just a matter of being able to fix bugs
ourselves if necessary - it is much safer to be self sufficient at the
next compiler upgrade, although we prefer a supported solution where
possible <g>

-- 
AlisdairM(TeamB)