2010-03-25 5 views
0

Je suis en train de tester un contrôle ActiveX non visuel basé sur un fichier .ocx enregistré que j'importe dans Delphi à l'aide de l'assistant fourni.Contrôles ActiveX avec les anciennes versions Delphi

Ensuite, je mets simplement le composant généré sur le formulaire principal d'une nouvelle application VCL.

Sous les anciennes versions Delphi (D5 et D2007), lorsque je lance l'application, cela déclenche un AV lors de l'initialisation du composant.

avec Delphi 2009: pas de problème, l'application démarre sans problème.

Mes questions sont les suivantes:

Y at-il des améliorations connues de la gestion ActiveX dans les dernières versions de Delphi qui peut expliquer cette différence?

Puis-je suspecter un bogue dans le contrôle ActiveX ou puis-je considérer que l'origine du problème provient d'anciennes versions de Delphi?

Je dois utiliser ce composant (si les tests sont OK) dans D2007. Pensez-vous qu'il est possible de corriger le problème AV sous D2007 en modifiant le fichier .tlb généré D2007 (par exemple en essayant d'utiliser le fichier D2009 généré)

PS: le contrôle ActiveX n'est pas nommé, car mon question est une question générale sur Delphi et ActiveX, pas sur un contrôle ActiveX spécifique.

Edit:
Avec D2007, l'erreur (une violation d'accès) apparaît pendant Application.CreateForm (TForm1, Form1);
et plus particulièrement lorsque le OleControl est créé:

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; 
+0

Il pourrait aider si vous nous avez dit l'erreur ... – Leo

+0

@Mef: OK plus d'infos sur l'erreur ajoutée. Il est étrange qu'avec D2009 TOleControl.CreateInstance (dans OleCtrls.pas) soit exactement la même fonction mais là l'appel de CoGetClassObject ne déclenche pas un AV. – DamienD

Répondre

1

Pour autant que je me souviens qu'il y avait des améliorations importantes à l'importation ActiveX/TLB Delphi 2009 (liées à la prise en charge Unicode) - qui pourraient l'expliquer. Dans mon expérience personnelle Delphi 7 et Delphi 2007 ont échoué à plusieurs reprises à importer certaines bibliothèques de type Windows 7 (diverses nouvelles interfaces pour fonctionner avec la nouvelle barre des tâches), mais Delphi 2009 a géré cela sans aucun problème. En ce qui concerne l'utilisation du fichier Delphi 2009 dans les versions antérieures, faites attention aux problèmes Unicode. De plus, il ne sera pas utile si le défaut est dans RTL ... Essayez de faire un wrapper ActiveX dans Delphi 2009 et l'utiliser dans Delphi 2007 - cela devrait fonctionner.

+0

merci de vos commentaires sur votre expérience. J'ai essayé votre idée avec le wrapper construit avec D2009 mais j'ai eu le même AV. J'envisagerai de déplacer mon projet vers D2009 ... car il semble être le seul moyen d'avoir une bonne gestion ActiveX. – DamienD

+0

J'accepte également votre réponse car il est clair que mon problème provient d'une gestion ActiveX/tlb incorrecte/incomplète dans les versions précédentes de Delphi. – DamienD

0

Je suis désolé d'être arrivé si tard après la bataille (5 ans plus tard), mais j'ai perdu tellement de temps sur cette question précise que j'ai pensé que je devais partager ce que j'ai vu et ce que j'ai fait pour le résoudre: 2 machines (win7 64/win 8.1) même delphi 7 (même version même build), même activeX (MapX pour le nommer) avec des fichiers .lic identiques contenant la clé faite de 59 caractères:

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

même importation produisant 2 TLB légèrement différent.

Celui qui travaille: (sur la victoire 8.1) contient ceci dans la procédure 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); 

qui se traduit par une 61 carbonisation clé

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

Le TLB qui ne fonctionne pas (Win 7 64) contient ceci:

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

qui se traduit par un 2 touche char

PM 

Remplacer un const par l'autre et recompiler le composant a résolu mon problème. Je ne sais pas vraiment ce qui s'est passé. Je sais juste que le fichier Import/TLB a produit un mauvais fichier .pas qui peut être corrigé manuellement.

Questions connexes