There is a serious bug in TConnectionPoint.AddSink:
AddSink is unable to add more than one notification sink.

Description

Reported by Matej Trampus; checked by Stefan Hoffmeister

In Delphi 3 (5.53), AxCtrls.PAS, there is a serious bug in TConnectionPoint.AddSink. AddSink is unable to add more than one notification sink.

Solution / workaround

The only solution is to modify the VCL source code and use this piece of code:

function TConnectionPoint.AddSink(const Sink: IUnknown): Integer;
var
  I: Integer;
begin
  I := 0;
  while I < FSinkList.Count do

{$IFDEF FixConnectionPointBug}
   if FSinkList[I] = nil then Break else Inc(I);
{$ELSE}
   if FSinkList[I] <> nil then Break else Inc(I); 
{$ENDIF}

  if I >= FSinkList.Count then
    FSinkList.Add(Pointer(Sink)) else
    FSinkList[I] := Pointer(Sink);
  Sink._AddRef;
  Result := I;
end;

Classes that are derived (inherit) from ActiveX controls give trouble in Delphi 4

Description

Reported by Stephen Millington; checked by Reinier Sterkenburg

If I create a new component from the TF1Book ActiveX component, and add it to a form, whenever I click on part of the control I get an access violation. I have had similar problems when trying to inherit from other ActiveX controls. This problem does not exist in Delphi 3.

Steps to reproduce:

1. Add a form to the project.
2. Add vcf1 to the uses clause.
3. Create a new type as follows :-

   type
     TNewF1Book = class(TF1Book)
     end;

4. In the OnCreate event of the form create a new variable of type TNewF1Book and set its parent property to that of the form.
5. Run the form and clicking on a cell will give an access violation.

This is a major problem since I wish to inherit from ActiveX controls and can't because of this bug. It is clearly a bug in Delphi 4 since this could be done without any problems in Delphi 3.
I know other people have experienced the same problem because there are articles on Inprise's newsgroups relating to the same problem.

Comment from checker:
I had the Access violations on assignment the Parent property, i.e. before I even got a chance to click on the control

Clinton R. Johnson followed up on this issue:
I can confirm that this bug existed in D4.0 and 4.01, but this bug HAS been fixed in D4.02. At least, for a part; if you want to use TF1Book descendants, you'll have to 're-generate' them yourself...
The ActiveX infrastructure has been significantly reworked to support this - It is however neccessary to have ActiveX imports which have been generated by D4.02, otherwise the activeX control behaves exactly as it did under D4.0(1)
If you have this problem under 4.02, either you have not re-imported the ActiveX control, or you have an old 4.0 or 4.01 copy of the ActiveX import floating around on your path.
You can tell if you are using the 4.02 generated version by reading the .InitControlData procedure from the import library.
It will look like :

procedure TWebBrowser.InitControlData;
const
  CEventDispIDs: array[0..17] of Integer = (
    $00000066, $0000006C, $00000069, $0000006A, $00000068, $00000071,
    $00000070, $000000FA, $000000FB, $000000FC, $00000103, $000000FD,
    $000000FE, $000000FF, $00000100, $00000101, $00000102, $00000104);
  CControlData: TControlData = (
    ClassID: '{8856F961-340A-11D0-A96B-00C04FD705A2}';
    EventIID: '{34A715A0-6587-11D0-924A-0020AFC7AC4D}';
    EventCount: 18;
    EventDispIDs: @CEventDispIDs;
    LicenseKey: nil;
    Flags: $00000000;
    Version: 300);
begin
  ControlData := @CControlData;
end;

If Version is 300, then you have the old import. Version should read 401 (which is a mistake on Inprise's behalf). Clearly, this is meant to indicate the minimum level for the new structure information. This fix was not available in 4.01 - Inprise used the wrong number, but it is applied consistantly, so its not a problem. (aside from giving the mistaken impression that the fix was available in 4.01).
Another visible difference is that the TControlData is now TControlData2, and has 1 additional field at the end of the record.