ActiveX controls with old Delphi versions

I'm testing a non visual ActiveX control based on a registered .ocx which I import into Delphi using the provided wizard.

Then, I simply put the generated component on the main form of a new VCL application.

Under old Delphi versions (D5 and D2007), when i launch the application, this raise an AV during the component initialization.

with Delphi 2009 : no problem, the application starts smoothly.

My questions are :

Are there known enhancements of ActiveX management in recent Delphi versions which can explain this difference ?

Can I suspect a bug in the ActiveX control, or can I consider the origin of the problem is from old Delphi versions ?

I need to use this component (if tests OK) in D2007. Do you think that it is possible开发者_JS百科 to correct the AV problem under D2007 by modifying the D2007 generated .tlb file (for example by trying to use the D2009 generated one)

PS: the ActiveX control is not named, because my question is a general question about Delphi and ActiveX, not about a specific ActiveX control.

Edit :

With D2007, the error (an Access Violation) appears during Application.CreateForm(TForm1, Form1);

and more specifically when the Olecontrol is created :

procedure TOleControl.CreateInstance;
var
  ClassFactory2: IClassFactory2;
  LicKeyStr: WideString;

  procedure LicenseCheck(Status: HResult; const Ident: string);
  begin
    if Status = CLASS_E_NOTLICENSED then
      raise EOleError.CreateFmt(Ident, [ClassName]);
    OleCheck(Status);
  end;

begin
  if not (csDesigning in ComponentState) and
    (FControlData^.LicenseKey <> nil) then
  begin
    // ON THE LINE BELOW : the call of CoGetClassObject raise an AV
    OleCheck(CoGetClassObject(FControlData^.ClassID, CLSCTX_INPROC_SERVER or
      CLSCTX_LOCAL_SERVER, nil, IClassFactory2, ClassFactory2));
    LicKeyStr := PWideChar(FControlData^.LicenseKey);
    LicenseCheck(ClassFactory2.CreateInstanceLic(nil, nil, IOleObject,
      LicKeyStr, FOleObject), SInvalidLicense);
  end else
    LicenseCheck(CoCreateInstance(FControlData^.ClassID, nil,
      CLSCTX_INPROC_SERVER or CLSCTX_LOCAL_SERVER, IOleObject,
      FOleObject), SNotLicensed);
end;

As far as I remember there were major enhancements to the ActiveX/TLB import in Delphi 2009 (related to Unicode support) - that might explain it.

In my personal experience Delphi 7 and Delphi 2007 repeatedly failed to import some Windows 7 type libraries (various new interfaces to work with new taskbar), but Delphi 2009 managed that without any problems at all.

As for using Delphi 2009 generated file in earlier versions - beware of Unicode issues. Plus it won't help if the defect is in RTL... Try to make a wrapper ActiveX in Delphi 2009 and use it in Delphi 2007 - that should work.

Sorry to barge in so late after the battle (5 years later as a matter of fact), but I wasted so much time on this precise issue that I thought I should share what I've seen and what I've done to solve it : 2 machines (win7 64 / win 8.1) same delphi 7 (same version same build), same activeX (MapX to name it) with identical .lic files containing the key made of 59 characters :

uQnZi2sFw22L0-MRa8pYX-1E2P8065-5N5M3459-3C934220-04969-6562

same import producing 2 slightly different TLB.

The one working : (on win 8.1) contains this in procedure TMap.InitControlData :

const
  CLicenseKey: array[0..61] of Word = ( $0075, $0051, $006E, $005A, $0069, $0032, $0073, $0046, $0077, $0032, $0032
    , $004C, $0030, $002D, $004D, $0052, $0061, $0038, $0070, $0059, $0058
    , $002D, $0031, $0045, $0032, $0050, $0038, $0030, $0036, $0035, $002D
    , $0035, $004E, $0035, $004D, $0033, $0034, $0035, $0039, $002D, $0033
    , $0043, $0039, $0033, $0034, $0032, $0032, $0050, $0030, $002D, $004D
    , $0030, $0034, $0039, $0036, $0039, $002D, $0036, $0035, $0036, $0032
    , $0000);

which translates to a 61 char key

uQnZi2sFw22L0-MRa8pYX-1E2P8065-5N5M3459-3C93422P0-M04969-6562

The TLB that does not work (win 7 64) contains this instead:

const
  CLicenseKey: array[0..2] of Word = ( $0050, $004D, $0000);

which translates to a 2 char key

PM

Replacing one const with the other and recompiling the component solved my issue. I don't really know what happened. I just know the Import/TLB produced a bad .pas file that can be corrected manually.