Le modèle COM

L'interface est une description des caractéristiques supportées par un objet COM. Elle définit les méthodes et les propriétés de l'objet accessibles si on connaît l'interface. Dans le modèle COM, on ne manipule un objet que via des interfaces.

Une interface doit être considérée comme un prototypage de routine transposé aux composants. En effet, le prototypage de routine permet au compilateur de faire un contrôle de type avant l'appel de la routine et au développeur d'appeler la routine. Une interface permet principalement au développeur de savoir comment manipuler un composant.

Une interface n'existe pas, c'est une description. Ce qui existe réellement, c'est le code de l'objet qui implémente l'interface.
C'est pour cette raison que l'on représente graphiquement un objet COM de cette manière :

Imaginons un objet COM proposant les interfaces IA et IB, constitué de deux instances A et B. Un composant externe n'a pas connaissance des objets A et B. Il doit posséder les définitions des interfaces IA et IB pour communiquer avec le composant.

Dans un langage objet, la manière la plus simple de définir une interface est d'utiliser la notion de classe abstraite pure.
Il s'agit d'une classe ne comportant que des méthodes abstraites :

type
  TZipper = class
  public
    procedure ZipFile; virtual; abstract;
    procedure UnZipFile; virtual; abstract;
  end;

Cette déclaration vous assure que toutes les classes dérivées de la classe TZipper comporteront les méthodes ZipFile et UnZipFile. On parle alors de contrat.

Afin que vous ne soyez pas tenté de définir des méthodes non abstraites ou des données membres dans une classe abstraite pure, Inprise à introduit le mot clé interface . L'avantage de l'utilisation de ce mot clé par rapport à l'utilisation d'une classe abstraite est qu'il n'est pas possible de déclarer de données membres au sein d'une interface, et que toutes les méthodes sont obligatoirement publiques et abstraites. De plus, ce mot clé facilite l'association d'un GUID à l'interface pour l'identifier de manière unique. Consultez le paragraphe portant sur l'identification pour plus de détails.

Voici la même classe TZipper définie par le mot clé interface.

type
  IZipper = interface
    procedure Zip;
    procedure UnZip;
  end;

Voici quelques règles introduites avec ce mot clé :

• dans une interface, toutes les méthodes sont publiques et par conséquent, l'utilisation des opérateurs de portées des classes n'a pas de sens ;
• par convention dans les sources de Delphi, le nom d'une interface débute par « I » et non par « T » comme pour les classes ;
• de même que les classes abstraites, une interface peut ne pas être instanciée et sera ignorée de toute façon par le compilateur. Mais à la différence de celle-ci, une interface ne peut pas être partiellement implémentée par une classe dans l'espoir qu'une classe dérivée implémente le reste. Une classe implémentant une interface doit implémenter toutes les entrées de l'interface.

Une interface peut proposer une propriété à l'aide du mot clé property . Mais comme elle ne peut déclarer de données membres, les accès en lecture et en écriture se font obligatoirement à l'aide de méthodes.

type
 IZipper = interface
  procedure Set_Filename(f : string);
  function Get_Filename : string;
  property Filename : string read Get_Filename write Set_Filename;
 end;

Note
Par convention, les méthodes d'accès en lecture et en écriture pour une propriété doivent être préfixées par Get_ et Set_ pour un contrôle ActiveX.

Le mot clé interface n'est reconnu que par le langage Pascal. Comment peut-on dans ce cas déclarer une interface pour d'autres langages ?

La réponse est l'utilisation de l'IDL. Il s'agit d'un langage de définition d'interfaces. Ce langage est transparent dans Delphi, et vous ne le rencontrerez que très rarement.

Mais l'approche standard est de définir un fichier IDL, puis d'utiliser un utilitaire tel que MIDL de Microsoft pour générer des classes C++.

Voici l'équivalent de l'interface IZipper, tel que déclarée ci-dessus, en langage IDL :

[
 uuid(F2737788-5902-11D2-8980-00600844A34A),
 version(1.0),
 helpstring("Interface pour Zipper Objet")
]
 interface IZipper: IUnknown
{
 [propget, id(0x00000002)]
 void _stdcall Filename([out, retval] long * Value );
 [propput, id(0x00000002)]
 void _stdcall Filename([in] long Value );
};

Delphi, quant à lui, dispose d'un éditeur de bibliothèque de types pour définir visuellement une interface. Cet utilitaire dispose d'une page nommée IDL permettant à tout moment de consulter l'équivalent de l'interface Pascal en langage IDL. Vous avez alors la possibilité de sauver ce texte source afin qu'il soit utilisé pour d'autres langages.

Cette opération est aussi réalisable avec l'utilitaire OLEView de Microsoft qui lit directement les bibliothèques de types et permet une exportation des interfaces en langage IDL. Inversement, à partir d'une source IDL, vous pouvez obtenir une bibliothèque de types en compilant le source à l'aide de l'exécutable MIDL.

La portabilité d'une interface est liée au standard défini par le langage IDL.

Le terme de coClasse est employé pour désigner une classe qui implémente une ou plusieurs interfaces. Le moyen utilisé en langage Pascal s'apparente à celui de l'héritage multiple qui existe dans d'autres langages orientés objet :

type
  IZipHuffman = interface
    procedure ZipFile; safecall;
  end;

  TZipper = class(TInterfacedObject, IZipHuffman)
    // interface IZipHuffman
procedure ZipFile; safecall;
end;

Une coClasse doit suivre les règles suivantes :

• elle doit obligatoirement implémenter toutes les entrées d'une ou des interfaces qu'elle supporte ;
• elle doit obligatoirement dériver d'une classe de base et celle-ci doit être la première listée.

La première règle est une question de bon sens. Si la coClasse n'implémente pas toutes les entrées des interfaces qu'elle doit implémenter, alors que produira l'appel à l'une des entrées non définies ?

La deuxième règle semble être un choix de Inprise pour simplifier l'analyse du code source. En effet, sans cette règle, le compilateur doit s'assurer que, parmi la liste des noms fournis dans la déclaration d'une classe, il n'y ait qu'une classe et que les autres soient bien des interfaces. Vous pouvez dériver de n'importe quelle classe, mais pour faciliter l'implémentation de COM, il est préférable de dériver au moins de la classe TInterfacedObject, car elle implémente l'interface IUnknown, nécessaire à tous les objets COM. Consultez le paragraphe qui suit pour plus d'informations.

Le langage Pascal n'autorise pas l'héritage multiple, mais en revanche, il autorise l'implémentation d'interfaces multiples. Voici une coClasse de l'interface IZipHuffman. Une coClasse qui implémente les interfaces IZipHuffman et IFile se déclare de cette manière :

type
  IZipHuffman = interface
    procedure ZipFile; safecall;
  end;

  IFile = interface
    function GetFilename : string; safecall;
    procedure SetFilename(f : string); safecall;
  end;

  TZipper = class(TInterfacedObject, IZipHuffman, IFIle)
    // interface IZipHuffman
    procedure ZipFile; safecall;
  
    // interface IFile
    function GetFilename : string; safecall;
    procedure SetFilename(f : string); safecall;
end;

L'interface IUnknown

Chaque développeur est libre de définir ses propres interfaces. Dans ce cas, comment se déplacer dans la mémoire d'un objet pour utiliser telle ou telle interface ? Comment le programme fait-il pour exécuter la méthode correspondant à une entrée d'une interface ?

À ces deux questions, voici leur réponse :

• en ce qui concerne les méthodes, il y a un fort couplage entre l'interface et la table des méthodes virtuelles d'un objet dans Delphi ;
• pour les interfaces, tous les objets COM doivent supporter l'interface IUnknown comme interface de base. Par conséquent, l'affectation d'un objet COM à une variable de type IUnknown fait toujours pointer la variable sur cette interface.

Ne connaissant pas un objet, il est toujours possible de demander son interface IUnknown. L'avantage est que cette interface décrit trois méthodes, dont une nommée QueryInterface permettant l'accès à d'autres interfaces supportées par l'objet.

Voici la définition de l'interface IUnknown :

IUnknown = interface
  ['{00000000-0000-0000-C000-000000000046}']
  function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
  function _AddRef: Integer; stdcall;
  function _Release: Integer; stdcall;
end;

Toutes les interfaces que vous définirez avec le mot clé interface héritent implicitement de l'interface IUnknown. Chaque objet COM doit implémenter les trois méthodes essentielles au bon fonctionnement du modèle :

• la méthode QueryInterface permet d'interroger l'objet sur l'implémentation ou non d'une interface dans celui-ci. Il en est de la responsabilité de chaque programme d'implémenter la manière dont une interface est retrouvée ;
• la méthode _AddRef doit être appelée systématiquement lorsque l'objet COM est créé. Généralement, en Pascal, vous n'aurez pas à faire cet appel, puisque le constructeur des objets le fait. Le but de cette méthode est d'incrémenter de 1 le compteur de référence de l'objet ;
• la méthode _Release doit être appelée lorsque l'objet n'est plus utilisé. Elle a pour but de décrémenter le compteur de référence de l'objet, et si celui-ci est nul, le destructeur de l'objet doit être appelé afin de libérer la mémoire de l'objet.

Ces trois méthodes doivent obligatoirement être définies pour chaque objet COM.

Afin de ne pas avoir à le faire systématiquement, les différentes classes de base de Delphi, compatibles COM, implémentent cette interface. C'est le cas des classes TInterfacedObject, TComObject, TTypedComObject, TAutoObject, etc.

Note Généralement, vous n'aurez pas à gérer le compteur de référence d'un objet COM, Delphi s'en charge pour vous.

Dans le langage Pascal, une variable de type interface est en fait un pointeur sur une zone mémoire de l'objet qui l'implémente. Cette zone mémoire contient l'adresse de la table des méthodes virtuelles de l'objet. C'est pour ces raisons que l'on dit qu'une interface est un double pointeur.

Les différentes entrées d'une interface correspondent à un déplacement dans la table virtuelle de l'objet.

Voici l'exemple qui montre l'utilisation de l'entrée QueryInterface afin de trouver une interface particulière dans un objet. Cet exemple montre une routine, TestZip, qui reçoit en paramètre un objet COM. Elle interroge l'objet reçu afin de savoir s'il supporte l'interface IZipper. Si c'est le cas, elle appelle la méthode ZipName.

type
 IZipper = interface
 ['{0A327261-2DE2-11D2-88E2-00600844A34A}']
 procedure ZipName; safecall;
end;


TMp3 = class(TInterfacedObject, IZipper)
 procedure ZipName; safecall;
end;

TVideo = class(TInterfacedObject)

end;

procedure TestZip(o : TObject);

var ik : IUnknown;
    z : IZipper;

begin
 if o.GetInterface(IUnknown, ik) then
 if ik.queryInterface(IZipper, z)=S_OK then z.ZipName;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
 TestZip(TMp3.Create); // un message s'affichera
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
 TestZip(TVideo.Create); // aucun message ne sera visible
end;

{ TMp3 }
procedure TMp3.ZipName;
begin
 ShowMessage('ZipperName');
end;

L'utilisation d'un objet COM en tant qu'objet du langage Pascal, ne change en rien aux règles prédéfinies par le langage Pascal objet. Une variable de type class étant une référence, donc un pointeur, tout objet Pascal créé doit être manuellement détruit. Certains objets sont codés pour libérer leurs composants. Par exemple, la fermeture d'une fiche entraîne automatiquement la libération de tous les objets attribués à la fiche, car du code spécifique a été prévu pour.

En revanche, tout se complique avec l'utilisation des interfaces !

En effet, lorsqu'on manipule un objet COM via une interface, ce sont les règles du modèle COM qui rentrent en vigueur. Chaque objet COM défini par l'implémentation de l'interface IUnknown, un mécanisme de compteur de référence d'utilisation du composant. Ceci est très important, car c'est le seul mécanisme qui permet de détruire un objet de la mémoire lorsque l'objet est distribué.

Par conséquent, si le code suivant crée un objet de type TTest, quelle que soit la nature de cet objet, l'instance créée ne sera libérée de la mémoire qu'à la fin d'exécution du processus.

procedure TForm1.Button1Click(Sender: TObject);
var  T : TTest;
begin
 T:=TTest.Create;
end;

Si TTest était un composant Edit, l'instance créée pourrait être montrée, et dans ce cas, l'instance reste après l'appel du gestionnaire d'événement.

Si au lieu d'utiliser une variable de type référence sur la classe, on utilise une variable d'une interface supportée par l'objet TTest, il en va autrement :

procedure TForm1.Button1Click(Sender: TObject);
var i : ITest;
begin
 i:=TTest.Create;
end;

En effet, dans ce cas, l'instance de la classe TTest créée est immédiatement libérée à la sortie du gestionnaire d'événement. La raison est que l'objet COM étant utilisé par une interface, les méthodes _AddRef et _Release sont utilisées. Par conséquent, l'affectation de l'objet COM à la variable i a pour conséquence d'incrémenter le compteur de référence, le positionnant ainsi à 1. Lorsque le gestionnaire d'événement se termine, les variables locales sont libérées. La variable i ne pointe alors plus sur l'objet créé. La méthode _Release est appelée et comme le compteur de référence passe à 0, l'objet COM est détruit de la mémoire.

Du fait qu'une classe Delphi peut dériver d'une autre classe, des masquages d'interfaces peuvent se produire. En effet, supposons qu'une classe TA implémente une interface nommée IA disposant d'une entrée nommée ProcStatic. Si une classe TB dérive de TA, sans implémenter l'interface IA, elle le supporte par héritage. Par conséquent, le code suivant fonctionne :

type
  IA = interface
    procedure Proc; safecall;
  end;

  TA = class(TInterfacedObject, IA)
    procedure Proc; safecall;
  end;

  TB = class(TA)
  end;

...

procedure TForm1.Button1Click(Sender : TObject);
var  IntfA : IA;
begin
  IntfA:=TB.Create;
  IntfA.Proc;
end;

Si la classe TB dispose d'une méthode de même signature que celle de l'entrée de l'interface IA sans l'implémenter, cette méthode ne sera pas liée à l'interface IA, et donc ne sera pas accessible via cette interface. La sollicitation de l'entrée appellera le code implémenté dans la classe TA.

Dans le cas où la classe TB implémente aussi l'interface IA, les méthodes de signature identique à celle de l'interface seront alors liées à l'interface. Par conséquent, l'appel d'une entrée de l'interface IA, appellera le code défini dans la classe d'où vous avez obtenu une instance.

Ce cas est obtenu lorsque la classe de base TA définie une méthode virtuelle pour l'entrée de l'interface IA, comme ceci :

type
 
 IA = interface
   procedure ProcVirtual; safecall;
 end;

 TA = class(TInterfacedObject, IA)
   procedure ProcVirtual; virtual; safecall;
 end;

Dans ce cas, que la classe TB surcharge ou non la méthode ProcVirtual , en implémentant ou non l'interface IA, l'appel de cette entrée d'un pointeur sur l'interface d'une instance de TB, déclenche le code implémenté dans TB. Bien entendu, une interface obtenue de l'instance TB appellera la méthode définie dans TB.

La redirection

Il se peut qu'une classe implémente deux interfaces qui disposent chacune d'une entrée de signature identique. La coClasse a deux possibilités, soit elle définit une méthode unique pour ces deux entrées, soit elle définit une méthode distincte à chacune.

Pour que l'explication soit plus explicite, nous nous appuierons sur un exemple utilisant les deux interfaces suivantes :

type
  IZipHuffman = interface
    procedure ZipFile; safecall;
  end;

  IZipLempel = interface
    procedure ZipFile; safecall;
  end;

On suppose que l'utilisation de l'interface IZipHuffman permet une compression avec la méthode Huffman, tandis que l'interface IZipLempel propose une compression LZW. Supposons maintenant une classe désirant implémenter ces deux interfaces. Un conflit se pose pour différencier l'implémentation de ces deux entrées.

Puisque les deux entrées sont identiques, la coClasse ne peut définir qu'une méthode disposant de cette signature. Le code suivant est accepté par le compilateur Pascal :

TZipper = class(TInterfacedObject, IZipHuffman, IZipLempel)

procedure ZipFile; safecall;

end;

...

procedure TForm1.Button1Click(Sender: TObject);
var    zHuffman : IZipHuffman;
    zLempel : IZipLempel;

begin
 zHuffman:=TZipper.Create;
 zHuffman.ZipFile; // appel de ZipFile de TZipper

 zLempel:=TZipper.Create;
 zLempel.ZipFile; // appel de ZipFile de TZipper
end;

Dans cet exemple, une instance de la classe TZipper manipulée avec l'interface IZipHuffman ou IZipLempel produira le même appel si l'entrée ZipFile est sollicitée.

Si au contraire, on désire différencier l'entrée ZipFile pour chacune des interfaces, on se doit de donner une implémentation différente par interface. Ceci est réalisable en redirigeant les implémentations des entrées sur des méthodes nommées différemment pour éviter les conflits de nom.
La redirection s'effectue en affectant à l'entrée spécifique d'une interface une méthode de la classe de nom quelconque, mais disposant d'une signature identique.

Voici comment utiliser cette technique pour définir un code spécifique à l'entrée ZipFile des interfaces IZipHuffman et IZipLempel :

TZipper = class(TInterfacedObject, IZipHuffman, IZipLempel)
  procedure IZipHuffman.ZipFile = ZipFileHuffman;
  procedure IZipLempel.ZipFile = ZipFileLempel;
  procedure ZipFileHuffman; safecall;
  procedure ZipFileLempel; safecall;
end;

Par conséquent, le comportement de l'objet Zipper diffère selon l'interface avec laquelle on le manipule.

La délégation

Avec le produit Delphi, Inprise a introduit la notion de RAD avec un modèle de délégation de code dans la fiche. Cela signifie qu'un gestionnaire d'événement est implémenté dans le code de la fiche et non dans l'objet sur lequel porte l'action. Si ce choix ne respecte pas la philosophie de la programmation objet, il simplifie énormément l'écriture de code. Tout le code des objets se trouve dans la fiche.

Cette même technique est applicable à l'implémentation des interfaces. Elle a aussi pour but de simplifier l'implémentation des interfaces en n'implémentant pas l'interface là où elle est utilisée. En réalité cette technique fournit deux avantages :

• une classe peut utiliser l'interface implémentée par une autre classe sans faire de l'héritage ;
• une classe peut utiliser l'interface implémentée par une autre classe sans faire d'agrégation « manuellement » par l'écriture de code.

Supposons qu'une classe existante implémente déjà une interface à laquelle vous aimeriez bien doter un nouvel objet. Par exemple, la classe TZipper implémente l'interface IZipper permettant la compression et la décompression de fichiers. Vous désirez définir un composant TZipperFileListbox dérivé de la classe TFileListbox, qui bien sûr devra être muni de la compression et de la décompression. Si vous déclarez la classe TZipperFileListbox de la manière qui suit, vous devez implémenter l'interface IZipper dans cette nouvelle classe :

type
  TZipperFileListbox = class(TFileListbox, IZipper)

...
end;

Et par conséquent, vous devez implémenter l'interface IUnknown et l'interface IZipper, car la classe TFileListbox n'implémente aucune de ces deux interfaces. Cela est très frustrant, puisque la classe TZipper implémente déjà IZipper et IUnknown. Avec l'héritage multiple, le problème serait résolu en faisant dériver la classe TZipperFileListbox des deux classes :

type
  TZipperFileListbox = class(TFileListbox, TZipper)
  end;

La classe TZipperFileListbox par ce biais implémenterait les deux interfaces. Or en Pascal, comme on le sait, l'héritage multiple de classes n'existe pas !

Dans de telles situations, la seule solution envisageable est l'agrégation. La classe TZipper devient une donnée membre de la classe TZipperFileListbox et les méthodes associées aux entrées de l'interface IZipper ne font qu'appeler les méthodes correspondantes de cette donnée membre. Cette technique fonctionne bien, mais comme il convient aussi d'implémenter l'interface IUnknown, elle s'avère pénible à l'écriture.

La délégation d'interface résout élégamment ce problème. Elle permet à une classe d'implémenter une interface à partir du code contenu dans une autre. Cette classe hôte n'implémente pas obligatoirement l'interface, elle doit uniquement disposer de méthodes dont les signatures correspondent à celles des entrées de l'interface à implémenter.

La syntaxe choisie pour cela s'apparente à celle de la définition d'une propriété. Il faut définir une propriété en lecture seule du type de l'interface à implémenter ou d'une classe supportant cette interface, et utiliser le mot clé implements pour préciser l'interface implémentée.

Voici la syntaxe

property PropName : [Interface|Class] read FData implements Interface;

Il en résulte alors deux possibilités, soit la propriété est de type interface, soit elle est de type objet. Le choix doit être pris suivant que l'on désire on non utiliser la donnée membre soit comme objet, soit comme interface.

Et voici un exemple :

property MonIntf : IMonIntf read FMonIntf implements IMonIntf;

Voici un exemple d'implémentation de la classe TZipperFileListbox utilisant la délégation d'interface avec une classe qui implémente l'interface voulue

type
  IZipper = interface
    procedure ZipFile; safecall;
    procedure UnZipFile; safecall;
  end;

  TZipper = class(TAutoInterfaced, IZipper)
    procedure ZipFile;
    procedure UnZipFile;
  end;

  TZipperFileListbox = class(TFileListbox, IZipper)
  private
    FZipper : IZipper;
  public
    constructor Create(AOwner : TComponent); override;
    property Zipper : IZipper read FZipper implements IZipper;
  end;

constructor TZipperFileListbox.Create(AOwner : TComponent);
begin
  inherited Create(AOwner);
  FZipper := TZipper.Create;
end;

Notez l'absence de destructeur pour libérer la mémoire de l'objet.

La création d'un objet COM disponible sur la machine locale est réalisée par la routine CreateCOMObject définie dans l'unité ComObj . Cette routine simplifie la création d'objets COM, car elle appelle la routine de l'API Windows CoCreateInstance qui nécessite plus de paramètres.

const CLASS_TestZipper: TGUID = '{F2737798-5902-11D2-8980-00600844A34A}';

type

 ITestZipper = interface(IUnknown)
  ['{F2737796-5902-11D2-8980-00600844A34A}']
  procedure Process(const Filename: WideString); stdcall;
 end;

procedure TForm1.Button1Click(Sender: TObject);
var itz : ITestZipper;

begin
 itz:=CreateCOMObject(CLASS_TestZipper) as ITestZipper;
 itz.Process('Fichier.bat');
end;

Si vous disposez de l'unité associée à la bibliothèque de type de l'objet COM, vous pouvez encore simplifier la construction de l'objet en vous aidant d'une méthode statique Create définie dans une classe qui porte le nom de l'interface, mais en remplaçant le préfixe 'I' par 'co'. Par conséquent, l'exemple au-dessus peut aussi s'écrire :

procedure TForm1.Button3Click(Sender: TObject);
var its :ITestZipper;

begin
 its:=coTestZipper.Create;
 its.Process('DDL.txt');
end;

La création d'un objet COM à l'aide de son ProgID n'est pas directe. En effet, il convient de rechercher dans la base des registres, un objet COM référencé dont la sous-clé ProgID contenant une valeur avec la chaîne du ProgID. Si cette valeur est trouvée, alors on récupère la clé parente qui contient le GUID de l'objet COM, afin d'appeler la routine CreateCOMObject. Afin de ne pas avoir à faire cette recherche dans la base des registres, Delphi propose la routine ProgIDToClassID pour obtenir le GUID d'un objet à partir de son ProgID. Voici un exemple d'utilisation :

procedure TForm1.Button2Click(Sender: TObject);
var itz : ITestZipper;

begin
 itz:=CreateCOMObject(ProgIDToClassID('Zipper.TestZipper')) as ITestZipper;
 itz.Process('Fichier.bat');
end;

Ainsi, si vous créez une sous-clé nommée « Coucou » dans la clé Shell associée à une extension de fichier, une option de même nom sera visible dans son menu contextuel. Si le titre de l'option est long, il est préférable de ne pas alourdir le nom de clé, et de créer une valeur par défaut disposant de la chaîne de caractères. Windows vérifie si une valeur par défaut existe et choisit la chaîne pour titre.

Pour chaque option de menu personnalisée, l'action à entreprendre si l'option est sélectionnée doit être précisée dans une sous-clé de la clé de l'option. Elle devra obligatoirement être nommée « Command » et avoir pour valeur par défaut, la séquence à exécuter. Exemple : menu contextuel statique :

Généralement, il s'agit d'un exécutable auquel on passe en paramètre le nom du fichier grâce à "%1 ». Par exemple, pour l'extension de fichier batch, voici la valeur de la clé Command :

%SystemRoot%\System32\NOTEPAD.EXE %1

Dans le cas où la sous-clé de Shell se nomme Open ou Print , et si ces clés ne disposent pas de chaînes de caractères pour leur valeur par défaut, alors Windows affichera « Ouvrir » et « Impression » et non « Open » et « Print ». Il s'agit là d'une exception, Windows les comprend comme des mots réservés et traduit le mot dans la langue courante du système d'exploitation.

Cette personnalisation est très simple, mais elle ne permet pas de changer de manière dynamique le nom de l'option ou le comportement de celui-ci. Ceci n'est possible que si un objet COM est associé à l'option.

L'ajout dynamique

L'ajout d'une option de menu de manière dynamique s'effectue en associant à l'option de menu un objet COM. Dans ce cas, on définit ce qu'on nomme une extension du shell. Il existe sept types d'extensions possibles qui doivent être définis dans une clé nommée ShellExt du fichier associé.

À chaque type d'extension du shell correspond une sous-clé spécifique. Ainsi, tous les contextes de menu associés à une extension de fichier doivent être définis dans la sous-clé ContextMenuHandlers .

Pour chacune des options que vous désirez rajouter, il faudra définir une sous-clé de ContextMenuHandlers de nom quelconque et dont la valeur par défaut est le CLSID de l'objet COM.

L'objet COM doit implémenter deux interfaces : IShellExtInit et IContextMenu. La première interface permet de récupérer le nom du fichier qui a sollicité le menu, tandis que la deuxième contient le code qui renvoie la chaîne de caractères de l'option de menu, une chaîne de commande, et le code qui doit être exécuté si l'option est sélectionnée.

L'interface IShellExtInit

L'interface IShellExtInit ne définit qu'une seule méthode Initialize qui vous permet de coder des instructions lorsque l'extension du Shell est déclenchée. En ce qui concerne le menu contextuel, l'implémentation de cette entrée n'est pas obligatoire, mais il s'agit du meilleur endroit pour récupérer le nom du fichier qui est sollicité.

Voici la définition de cette interface :

IShellExtInit = interface(IUnknown)
  [SID_IShellExtInit]
   function Initialize(pidlFolder: PItemIDList; lpdobj: IDataObject; hKeyProgID: HKEY): HResult; stdcall;
end;

Le paramètre lpdobj de l'entrée Initialize est un objet supportant l'interface IDataObject. Cette interface décrite pour le Glisser/déplacer donne des indications sur la nature des objets manipulés. Dans notre cas, IDataObject est capable de nous fournir le nom des fichiers sur lequel porte la demande du menu contextuel. Bien que les opérations à effectuer pour récupérer les différentes informations de l'interface IDataObject ont été vues dans le précédent paragraphe, nous pouvons aussi utiliser la routine QueryDragFiles pour récupérer plus simplement le nom du fichier manipulé.

L'interface IContextMenu

Lorsque le menu contextuel de l'objet est sollicité, l'entrée QueryContextMenu est appelée pour que l'objet COM puisse ajouter ses options.

Plusieurs options de menu peuvent être rajoutées, il suffit pour cela d'incrémenter de un le paramètre IndexMenu pour chacune des options et de spécifier comme valeur de retour, le nombre d'options rajoutées.

Pour identifier chaque option de menu, vous devez utiliser la valeur idCmdFirst sans dépasser idCmdLast . Lorsqu'une option est sélectionnée, la méthode InvokeCommand est appelée, et son paramètre contient l'indice associé à l'option de menu sollicitée.

Voici la définition de cette interface :

IContextMenu = interface(IUnknown)
 [SID_IContextMenu]
  function QueryContextMenu(Menu: HMENU;indexMenu, idCmdFirst, idCmdLast, uFlags: UINT): HResult; stdcall;
  function InvokeCommand(var lpici: TCMInvokeCommandInfo): HResult; stdcall;
  function GetCommandString(idCmd, uType: UINT; pwReserved: PUINT;pszName: LPSTR; cchMax: UINT): HResult; stdcall;
end;

Le fabricant de classe

Au lieu d'utiliser le fabricant de classe d'un objet COM de base, il est préférable de définir une classe dérivée et de personnaliser l'enregistrement.

En ce qui concerne un contexte de menu, l'enregistrement consiste à :

• créer la clé ShellEx pour l'extension de fichier si elle n'existe pas déjà ;
• créer la sous-clé ContextMenuHandlers si elle n'existe pas déjà ;
• ajouter une sous-clé et une valeur par défaut avec le GUID de l'objet COM dans la clé ContextMenuHandlers.

Une dernière opération est nécessaire pour Windows NT, il faut en effet « approuver » l'objet COM en définissant une sous-clé dans la clé SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved . Cette sous-clé devra porter le GUID de l'objet COM comme nom et avoir un descriptif de l'objet comme valeur par défaut de la clé.

Le code complet

Voici le code complet d'un exemple qui permet de mettre ou de supprimer les informations d'une DLL COM dans la base des registres de notre menu contextuel associé aux fichiers de type DLL :

Pour créer une page de propriétés pour un contrôle ActiveX, ajoutez au projet de ce contrôle un objet « Page propriétés » accessible dans le référentiel d'objet de la page ActiveX. Une nouvelle fiche sera ajoutée au projet, qui servira de support au dessin de la page de propriétés du contrôle.

Dessinez alors la page avec les informations que vous désirez proposer.

Le source de la page de propriétés dispose de deux méthodes vides. Il s'agit des méthodes UpdatePropertyPage et UpdateObject . La méthode UpdatePropertyPage est systématiquement appelée lorsque la page de propriétés s'affiche la première fois. Le code de cet événement permet donc de renseigner les différents champs de page de propriétés à partir du contrôle ActiveX. La méthode UpdateObject est quant à elle appelée lorsque la page de propriétés est validée. Cela permet de mettre à jour les propriétés du contrôle.

Une fois la page liée au contrôle, tous ses objets peuvent accéder au contrôle ActiveX par la donnée membre OleObject. Par conséquent, on peut affecter ou lire une information du contrôle par le biais de cette donnée membre. Ainsi, si votre contrôle ActiveX dispose d'une zone d'édition nommée ValeurMonetaire , voici comment vous lui affecterez une nouvelle valeur via une zone d'édition de la page de propriétés portant le nom Edit1 :

procedure TPropertyPage1.UpdateObject;
begin
    // Met à jour OleObject depuis vos contrôles
  OleObject.ValeurMonetaire.Text:=Edit1.Text;
end;

Pour pouvoir synchroniser la valeur présente dans la page de propriétés avec celle du contrôle ActiveX, il convient de faire l'affectation suivante :

procedure TPropertyPage1.UpdatePropertyPage;
begin
    // Met à jour vos contrôles depuis OleObject
  Edit1.Text:=OleObject.ValeurMonetaire.Text;
end;

L'enregistrement de la page de propriétés et du contrôle est l'étape ultime pour voir apparaître la page de propriétés lorsqu'on utilise le composant en phase de conception. Cette opération s'effectue en surchargeant la méthode DefinePropertyPages de la classe TPropertyPage représentant la page de propriétés. Normalement, l'expert Delphi vous génère le corps de cette méthode qui prend en paramètre une fonction nommée DefinePropertyPage. Le corps de cette méthode se résume alors à appeler cette fonction en lui fournissant en paramètre le CLSID de la page de propriétés qui est défini dans l'unité implémentant la page de propriétés. Par défaut, il est représenté par une constante dont le préfixe est class_ suivi du nom de la classe définissant la page de propriétés sans le T.

type
  TActiveFormX = class(TActiveForm, IActiveFormX)
   ...
   procedure DefinePropertyPages(DefinePropertyPage : TDefinePropertyPage); override;
   ...
  end;

implementation

uses ComServ, ActiveFormProp;

{$R *.DFM}

{ TActiveFormX }

...

procedure TActiveFormX.DefinePropertyPages(DefinePropertyPage : TDefinePropertyPage);
begin
 DefinePropertyPage(Class_PropertyPage1);
end;

...

begin

end.

Après installation de l'ActiveX, la page de propriétés est accessible par le menu contextuel du contrôle :

L'installation de DCOM est sommaire pour les postes fonctionnant sous Windows NT, puisqu'il est intégré dans ce système. En revanche, pour un poste fonctionnant sous Windows 95, vous devrez vous procurer l'exécutable DCOM95.exe et procéder à son installation.

Les outils nécessaires

Le modèle DCOM est implanté de manière native dans l'environnement Windows NT et doit être configuré par l'utilitaire DCOMCnfg . Par conséquent, aucun fichier ou programme supplémentaire n'est nécessaire : vous pouvez directement appeler l'utilitaire DCOMCnfg à partir de la ligne de commande ou de l'option Exécuter… du menu Démarrer de la barre des tâches.

En revanche, le système Windows 95 ne dispose pas de DCOM de manière native. Il faudra vous munir des programmes DCOM95.exe et DCOM95Cfg.exe disponibles sur le serveur Web de Microsoft.

Le programme DCOM95.exe installe la couche logicielle qui permet aux applications d'utiliser le modèle COM avec d'autres machines. Quant au fichier DCm95Cfg.exe , il installe l'utilitaire DCOMCnfg qui configure DCOM, c'est-à-dire la gestion de l'exportation et des droits d'accès sur les objets COM disponibles.

Une fois configuré, un poste sous Windows 95 peut aussi bien être un client qu'un serveur d'objets DCOM.

Note :
Selon les recommandations de Microsoft, pour certaines machines, il est conseillé de disposer de la version OSR2 de Windows 95 afin d'éviter d'éventuelles erreurs de connexion entre une machine sous Windows 95 et une autre sous Windows NT.

La configuration de la base des registres

Pour utiliser DCOM, quel que soit le poste à configurer, il convient de définir la valeur nommée LegacyAuthenticationLevel à 1 de la clé /HKey_Local_Machine/Software/Microsoft/OLE/ .

En ce qui concerne le poste serveur DCOM, il faut, en plus, définir une valeur nommée EnableRemoteConnect positionnée à `Y' pour `Yes' pour la même clé. Ceci permet aux objets autorisés d'être exécuté par d'autres machines.
Voici récapitulées les deux valeurs qui doivent être configurées :

HKey_Local_Machine
  Software
    Microsoft
      OLE
      EnableDCom = Y
      EnableRemoteConnect = Y (pour le poste serveur uniquement)
      LegacyAuthenticationLevel = 1

Le partage des répertoires du poste serveur

Que votre serveur soit sous Window NT ou sous Windows 95, il doit obligatoirement partager les répertoires qui contiennent des objets DCOM. Les clients ne doivent pas obligatoirement avoir des droits sur le répertoire partagé, une autre configuration permettra d'attribuer des droits de la machine serveur à un client distant.

La gestion des droits d'accès s'effectue sur le poste serveur pour toutes les connexions ou individuellement pour chaque objet COM partagé.

Le serveur d'appel RPC

Pour que DCOM puisse fonctionner, outre la configuration Réseau du poste, il convient pour le serveur DCOM que le service RPC soit chargé.

Le service RPC, pour Remote Procedure Call, permet l'exécution d'une procédure à distance et par conséquent, l'appel de routines liées à une interface pour un programme hôte.

Par défaut, ce service est automatiquement lancé sous Windows NT. Pour le vérifier, consultez la liste des services à partir du panneau de configuration de Windows NT, vous constaterez que le service « serveur d'appel RPC » est bien démarré.

Sous Windows 95, il convient de lancer manuellement l'exécutable rpcss à partir de la ligne de commande. Sans ce service, aucun objet ne peut être appelé à partir d'un autre poste client. Si l'exécutable rpcss.exe ne se lance pas, c'est que…

Si le poste Windows 95 est utilisé comme serveur DCOM, il est recommandé de mettre l'exécutable rpcss.exe dans le menu Démarrage.

L'installation de DCOM sous Windows 95

DCOM n'étant pas installé de manière native avec Windows 95, il convient de se prémunir et d'exécuter l'exécutable DCOM95.exe . Cet exécutable installe des DLL supplémentaires et l'utilitaire DCOMCfng.exe dans le répertoire de Windows.

La configuration réseau des postes Windows 95

La configuration des postes fonctionnant sous Windows 95 est la phase la plus délicate, car la configuration dépend à la fois de la nature et des caractéristiques voulues pour le poste. Le poste est-il client ou serveur ? Sous quelle version de Windows 95 fonctionne-t-il ? Quelle qu'en soit la réponse, le poste doit être correctement configuré en réseau.

X-B-1. Le protocole TCP/IP▲

X-B-2. La page « Configuration »▲

X-B-3. La page « Identification »▲

X-B-4. La page « Contrôle d'accès »▲

Une fois le réseau configuré, il vous appartient de rendre un objet disponible ou non à d'autres machines. Sur le poste serveur, chaque objet doit se trouver dans un répertoire partagé accessible par le poste client et DCOM doit être configuré sur le poste serveur via l'utilitaire DCOMCnfg . Si vous ne disposez pas de serveurs COM, consultez le paragraphe « Les tests par l'exemple » de ce chapitre.

L'utilitaire DCOMCnfg

Cet utilitaire permet de gérer l'accès, et donc la sécurité des objets COM disponibles sur une machine. Il existe quelques différences entre la version fournie avec Windows NT et celle de Windows 95. Ces différences sont minimes et essentiellement axées sur la sécurité. Comme pour la configuration réseau, les points communs seront les premiers abordés, puis les différences de la version sous NT seront expliquées.

X-C-1. La page Applications▲

X-C-2. La page Général▲

X-C-3. La page Emplacement▲

X-C-4. La page Sécurité▲

X-C-5. La page Identité sous Windows NT▲

...
var id : IDispatch;

begin
  id:=CreateRemoteCOMObject(`Nom_Machine', Class_ID) as IDispatch;
  ...
end;

Après avoir validé la boîte de dialogue, l'éditeur de bibliothèque de type s'affiche et montre les nœuds.

L'application Project1 contient une interface nommée ITestComObj et une coClasse nommée TestComObj.

Les services du serveur

L'ajout de service à un objet d'automatisation COM passe par l'ajout d'entrées dans une interface via l'éditeur de bibliothèque de type. Par conséquent, reportez-vous à son explication dans le chapitre portant sur COM.

La directive safecall

Les méthodes des objets COM sont souvent qualifiées par le mot clé safecall . En précisant une méthode de cette nature, le compilateur Pascal protège automatiquement le corps de la méthode des exceptions non trappées. En clair, une méthode définie comme suit :

type

  IUneInterface = interface
    procedure FaitQQ; safecall;
  end;

  TMonObject = class(TUneClasse, IUneInterface)
    ...
    procedure FaitQQ; safecall;
  end;

procedure TMonObjet.FaitQQ;
begin
  Montraitement;
end;
doit en réalité être lu de cette manière :

procedure TMonObjet.FaitQQ; safecall;
begin
  try
    Montraitement;
  except

  end;
end;

Le but de ce remplacement est d'empêcher qu'une exception ne se propage hors de la méthode en l'étouffant. C'est à la fois une question de sécurité et une question pratique pour les développements distribués, et donc pour l'automatisation.

En effet, si l'appel d'une méthode produit le soulèvement d'une exception dans celle-ci, une boîte de dialogue sera affichée. Lorsque le client et l'objet se trouvent sur la même machine, il suffit de fermer cette boîte de dialogue pour débloquer le serveur.

En revanche, si l'objet COM se trouve sur une machine distante, non seulement vous serez obligé de vous déplacer pour fermer la boîte de dialogue, mais vous ne serez pas averti que l'objet a déclenché une exception. L'objet ou/et votre application sembleront bloqués, d'où l'avantage d'empêcher qu'une exception se soulève et donc de préfixer les méthodes par la directive safecall .

L'enregistrement d'un serveur

Pour enregistrer temporairement le serveur d'automatisation défini dans un exécutable, il suffit de lancer une première fois l'exécution du programme. En revanche, pour enregistrer le serveur de manière durable, il convient de fournir /regserver en paramètre de la ligne de commande de l'exécutable. Et, pour ne plus enregistrer un serveur, il convient de fournir /unregserver .

Pour enregistrer un serveur d'objets d'automatisation de type DLL, il convient d'utiliser l'utilitaire tregsvr.exe fourni avec Delphi.

L'environnement MTS simplifie l'administration des serveurs, car un de ses gros avantages est qu'il n'est pas nécessaire de relancer le serveur lorsqu'un objet publié est modifié. En remplaçant un objet par une nouvelle version, tous les nouveaux clients bénéficient des nouvelles possibilités.

MTS gère l'activation et la désactivation des objets COM, il est donc capable de montrer à tout instant l'état de chaque composant installé. De la même manière, il est capable de lister tous les objets en cours d'utilisation qu'ils soient utilisés sans une transaction ou non. Il se comporte alors comme un outil de monitoring d'objets COM.

Les composants MTS sont installés dans des Lots (ou paquets suivant les traductions) et un composant peut appartenir à plusieurs Lots différents.

Un Lot donne un certain nombre d'avantages aux composants qui y sont installés. En fait un Lot isole un groupe de composants, permettant ainsi à ces composants de partager des données globales.

MTS apporte essentiellement les sept caractéristiques qui suivent :

• connexion aux bases de données ;
• applications MTS sécurisées ;
• gestion des composants ;
• monitoring des transactions ;
• activation JIT (spécifique aux objets MTS) ;
• propriétés partagées (spécifiques aux objets MTS) ;
• sécurité améliorée (spécifique aux objets MTS).

Les apports de MTS

Les connexions de bases de données compatibles avec MTS, telles que ODBC et BDE utilisent une gestion basée sur le recyclage de connexion afin de fournir plus de clients. Le principe est simple, dès qu'un client n'utilise plus l'objet MTS connecté à une base de données, sa connexion est récupérée si un autre client en fait la demande.

Non seulement cette technique permet de fournir plus de clients, mais elle permet aussi de consommer moins de ressources, et par conséquent de gagner en vitesse d'exécution, puisqu'il y a moins d'ouvertures et de fermetures de bases de données.

MTS utilise les droits de Windows NT pour accéder aux paquets et aux objets référencés. Par conséquent, l'administration et la gestion de la sécurité des objets restent homogènes et donc plus sûres.

Un serveur MTS peut solliciter un objet sur une autre machine serveur, bien qu'il dispose lui-même de ce composant dans le but de mieux répartir la charge de travail entre tous les serveurs du réseau.

Dans le cas où le client n'est pas configuré pour accéder à ce serveur, le serveur courant peut configurer la machine du client s'il dispose de DCOM afin de lui donner les moyens d'y accéder.

Sans que l'objet MTS soit prévu pour supporter les transactions, un serveur MTS peut faire participer cet objet dans une transaction et relancer la transaction en cas d'échec d'une transaction.

Un serveur MTS active les composants que lorsque cela est nécessaire. Cela signifie que si le code d'un objet est très peu sollicité, alors l'objet peut être déchargé de la mémoire, puis rechargé lorsqu'il est à nouveau sollicité. Du fait que durant sa vie, un objet peut être chargé et déchargé plusieurs fois, il perd à chaque fois son contexte. On dit que l'objet est « Standless ».

Mais cette même gestion est aussi applicable pour une autre demande d'un autre client sur un même objet. Le serveur désactive l'objet pour le premier client afin de servir le deuxième. L'avantage est que le serveur n'a pas besoin de créer plusieurs instances de l'objet, accélérant ainsi l'utilisation d'un objet.

En revanche, pour les objets conçus pour MTS, la désactivation n'est possible que si la transaction en cours est terminée. Ceci intervient lorsque la méthode SetAbort ou SetComplete est appelée. Dans ce cas, la désactivation de l'objet est immédiate.

Les composants peuvent partager des données entre composants du même paquet. Cette option permet de synchroniser des composants entre eux ou de conserver l'état des objets. Bien que devant être gérée par l'objet, cette possibilité offre une solution complète pour le partage des données.

La sécurité se décompose en deux types : programmatique et déclarative.

La sécurité programmatique s'appuie sur la sécurité NT existant. Elle est disponible pour tous les composants MTS. Elle permet d'affecter des droits aux paquets, aux composants et aux interfaces. Cette sécurité est disponible pour tous les systèmes qui disposent de DCOM.

En revanche, la sécurité déclarative n'est disponible que pour les paquets sous Windows NT. Elle est basée sur des rôles. Un rôle étant un groupe d'utilisateurs pouvant appeler les interfaces d'un composant.

Exemple de développement MTS

Dans les développements multiniveaux, les différentes couches peuvent mettre en jeu un ou plusieurs ordinateurs. Sur chacun des ordinateurs, un ou plusieurs objets peuvent être sollicités pour réaliser une tâche unique. Par exemple, une chaîne de production simplifiée de bilboquets disposant de trois machines créant chacune une pièce nécessaire à l'élaboration du jouet, peut être modélisée par le schéma suivant :

Exemple, le poste client envoi une requête à chacune des machines serveur dans le but que celles-ci réalisent la pièce nécessaire. Lorsque les trois demandes sont réalisées, le poste client peut ordonner à une machine tiers, l'assemblage des trois pièces. En revanche, si une des trois machines tombe en panne ou est incapable de réaliser la tâche demandée, le poste client doit en être averti.

Le rôle de MTS est de permettre au poste client de valider (commit) ou d'annuler (rollback) toutes les demandes d'un client.

Le service MTS gère aussi la gestion des ressources du système en chargeant et en déchargeant les DLL de serveur d'objet MTS.

De plus, si le service estime que le système nécessite des ressources, il est capable de décharger de la mémoire certains objets MTS en cours d'utilisation.

Lorsqu'un objet est utilisé dans une transaction, il doit signaler l'état de son traitement à l'aide des méthodes SetComplete ou SetAbort . Ceci peut être réalisé soit par l'objet lui-même, soit par le programme client. Dans ce dernier cas, l'objet MTS doit disposer d'entrée permettant l'appel de ces méthodes.

Ces méthodes positionnent un flag pour la transaction. Si à la sortie d'une méthode de l'objet MTS le flag reste positionné à SetAbort, une exception est soulevée dans l'application ayant appelé l'entrée. Dans ce cas, l'exception soulevée doit être gérée afin d'annuler la transaction avec l'appel de l'entrée Abort de l'objet transaction. Si aucune exception n'est soulevée, alors la transaction peut être validée avec l'appel de la méthode Commit . Voici un exemple d'une transaction faisant intervenir deux objets MTS :

procedure TForm1.Button15Click(Sender: TObject);
 var Transaction : ITransactionContextEx;

begin
  Transaction:=CreateTransactionContextEx;
  OleCheck(Transaction.CreateInstance(CLASS_ObjectFirst,IObjectFirst, ObjectFirst));
  OleCheck(Transaction.CreateInstance(CLASS_ObjectSecond,IObjectSecond, ObjectSecond));

 try
  ObjectFirst.DoWork;
  ObjectSecond.DoWork;
  Transaction.Commit;

 except

  Transaction.Abort;
    Raise;
  end;

end;

Dans un premier temps, on crée l'objet transaction, puis les deux objets MTS en protégeant leur appel par la routine OleCheck.

Dans un bloc protégé de type try..except , les traitements de chaque objet sont appelés. En cas de réussite des traitements, la transaction est validée par un Commit . Si un des traitements déclenche l'appel de SetAbort , alors une exception est soulevée provoquant l'annulation de la transaction.

Lorsqu'une transaction est annulée, il est nécessaire de défaire toutes les opérations ayant abouti avant l'échec.

Le terme de traitement multientrées désigne un traitement nécessitant l'appel de plus d'une entrée du même objet MTS pour pouvoir être complète. Dans ce cas, il est possible de positionner un flag avec l'appel de DisableCommit pour empêcher toute réussite de l'appel de la méthode SetComplete .

Pour autoriser la complétude du traitement de l'objet, la méthode EnableCommit doit être appelée.

La méthode IsInTransaction permet à un objet MTS de tester s'il est utilisé dans une transaction. Ceci est pratique pour par exemple n'autoriser l'utilisation d'un objet que si celui-ci participe à une transaction.