🚀 go-pugleaf

Sorry I've taken so long to get back. I am on the road at this time.


>
> Did the confirmation popup that appeared actually list the individual 
> components by name?  If not, then they were not registered properly.

  Yes

>
> Did the BCB5 project use Indy 9 or 10?  The fact that no icons appear on 
> the Form itself also suggests the components did not get registered 
> correctly.
>
   It used Indy5.

>
> Gambit

I decided to take another tack, figuring I had made hash of everything. I 
completely removed BDS2006 as well as removing all Indy references I could 
find. I then reinstalled BDS with all personalities and looked for indy 
related files. I had to use the Indy90 installation as per the BDS 
installation instructions for use with C++. I then looked for, and examined 
all the indy files I could find. I used "FileAlyzer" and looked for version 
references. Though some of the files were labeled dclIndyCore100.bpl, for 
example, they were really version 9 as was expected. There were some indy 
.dll files, but they seemed to be for .NET personalities. There were no 
files that the versions claimed to be for C++; only .NET or Delphi.
In the files created by unzipping the latest Indy snapshot and compiling, 
only one .dll file was generated, Mono.Security.dll.

I did notice - since I also still have installed BCB ver. 5 which uses 
Indy50 - that there were two files that were labeled Indy90.bpl and 
dclIndy90.bpl (with similar versions for indy50). In the latest snap shot, 
there are no Indy100.bpl only IndyCore100.bpl, etc. That is the word Indy100 
alone, as opposed to IndySomething100.bpl.

In the run-time part of the Component->Install Packages window, there is a 
reference only to "Indy".

Should there be an Indy100.bpl and a dclIndy100.bpl generated in the batch 
files of the latest snapshot, and is that the problem?

Should there be more .dll files generated by the snapshot, and is the lack 
of those files the problem?