Streaming components/fr

From Lazarus wiki
Jump to navigationJump to search

│ Deutsch (de) │ English (en) │ français (fr) │ 日本語 (ja) │ polski (pl) │ português (pt) │

Introduction

Normalement, quand vous voulez stocker des données sur le disque ou le réseau, vous devez écrire le code pour le chargement et l'enregistrement de chaque propriété. Ce tutoriel décrit comment écrire des classes qui peuvent être chargées et enregistrées à partir de flux sans charge supplémentaire de code de chargement/enregistrement, tout cela en utilisant la RTTI.

Vous trouverez un exemple dans les sources de Lazarus démontrant comment enregistrer un TGroupBox avec un enfant TCheckBox vers un flux et relire ce flux pour créer une copie des deux composants. Voir <lazaruspath>/examples/componentstreaming/

En combinaison avec Les contrôles RTTI, vous pouvez réduire au minimum la quantité de code nécessaire pour connecter les données du programme avec le GUI et le Disque/Réseau.

TComponent / TPersistent

La classe TPersistent est définie dans l'unité Classes et utilise la directive de compilation {$M+} . Cette directive dit au compilateur de créer de l'information pendant le temps d'exécution (RTTI). Lui et tous ses descendants comprennent alors une nouvelle section de classe published. Les propriétés published sont visibles comme si elles étaient public, mais leur structure est aussi accessible pendant le temps d'exécution. Cela signifie que toute propriété published peut être lue et écrite pendant ce temps d'exécution. Par exemple, l'EDI emploie cette technique pour travailler avec des composants dont il n'a jamais entendu parler.

TComponent étend les possibilités de TPersistent par sa capacité à posséder des composants enfants. Cette capacité est importante pour le traitement des flux : un composant est le composant racine (appelé parfois lookup root) qui gère une liste de composants enfants.

TReader / TWriter

Ce sont les classes qui permettent d'écrire/de lire un TComponent vers/depuis un flux (Voir CreateLRSReader et CreateLRSWriter). Elles emploient un Pilote pour lire/écrire dans un format spécial. A l'heure actuelle, il y a un lecteur (TLRSObjectReader), un outil d'écriture (TLRSObjectWriter) pour le format d'objet binaire défini dans l'unité LResources et un outil d'écriture (TXMLObjectWriter) pour TDOMDocument défini dans Laz_XMLStreaming. L'unité LResources contient également des fonctions pour convertir le format binaire en texte et l'inverse (LRSObjectBinaryToText, LRSObjectTextToBinary). La bibliothèque LCL utilise de préférence le codage UTF8 pour les chaînes de caractères tandis que Delphi préfère Widestrings . Par conséquent, vous disposez aussi de quelques fonctions de conversion si bien que vous pouvez tout aussi bien travailler avec des données de flux provenant de Lazarus qu'avec des données au format binaire de Delphi.

Streaming Collections

Consultez TCollection/fr#Streaming

Il s'agit d'un exemple complet qui montre comment utiliser les classes TCollectionItem, TCollection et les gérer par des flux grâce à TComponent.

Écrire votre propre composant - Partie 1

Un composant personnalisé peut être aussi simple que : 

type
 TMyComponent = class(TComponent)
 private
   FID: integer;
 published
   property ID: integer read FID write FID;
 end;

Écrire un composant dans un flux

L'unité LResources a une fonction pour cela : 

 procedure WriteComponentAsBinaryToStream(AStream: TStream; AComponent: TComponent);

Elle écrit un composant dans le format binaire du flux. Par exemple : 

procedure TForm1.Button1Click(Sender: TObject);
var
  AStream: TMemoryStream;
begin
  AStream:=TMemoryStream.Create;
  try
    WriteComponentAsBinaryToStream(AStream,AGroupBox);
    ... enregistre le flux quelque part ...
  finally
    AStream.Free;
  end;
end;

Lecture d'un composant depuis un flux

L'unité LResources a une fonction pour cela : 

 procedure ReadComponentFromBinaryStream(AStream: TStream;
   var RootComponent: TComponent; OnFindComponentClass: TFindComponentClassEvent; TheOwner: TComponent = nil);
  • AStream est le flux contenant un composant au format binaire.
  • RootComponent est soit un composant existant dont les données seront écrasées, soit c'est nil et un nouveau composant sera créé.
  • OnFindComponentClass est une fonction qui est utilisée par TReader pour obtenir la classe à partir des noms de classe dans le flux. Par exemple :
procedure TCompStreamDemoForm.OnFindClass(Reader: TReader;
  const AClassName: string; var ComponentClass: TComponentClass);
begin
  if CompareText(AClassName,'TGroupBox')=0 then
    ComponentClass:=TGroupBox
  else if CompareText(AClassName,'TCheckBox')=0 then
    ComponentClass:=TCheckBox;
end;
  • TheOwner est le propriétaire du composant pendant la création d'un nouveau composant.

Propriétés pouvant être stockées dans un flux

Il y a quelques limitations concernant les types TReader/TWriter qui peuvent être stockés dans un flux :

  • Les types de base sont admis pour un flux : string, integer, char, single, double, extended, byte, word, cardinal, shortint, les pointeurs de méthode, etc. ;
  • TPersistent et ses descendants sont aussi admis pour un flux ;
  • Les enregistrements (records), les objets et les classes ne descendant pas de TPersistent ne peuvent pas être stockés dans un flux . Pour les stocker dans un flux, vous devez surcharger certaines méthodes de TReader/TWriter. Voir ci-dessous Mise en flux de données courantes - DefineProperties.

Mise en flux de données courantes - DefineProperties.

Vous pouvez mettre en flux des données arbitraires additionnelles en écrasant DefineProperties. Ceci permet de mettre en flux toutes les données qui n'ont aucun type de base. Par exemple, pour mettre en flux une variable FMyRect: TRect de votre composant , ajoutez les trois méthodes suivantes à votre composant : 

procedure DefineProperties(Filer: TFiler); override;
procedure ReadMyRect(Reader: TReader);
procedure WriteMyRect(Writer: TWriter);

avec le code suivant : 

procedure TMyComponent.DefineProperties(Filer: TFiler);
var
  MyRectMustBeSaved: Boolean;
begin
  inherited DefineProperties(Filer);
  MyRectMustBeSaved:=(MyRect.Left<>0)
                     or (MyRect.Top<>0)
                     or (MyRect.Right<>0)
                     or (MyRect.Bottom<>0);
  Filer.DefineProperty('MyRect',@ReadMyRect,@WriteMyRect,MyRectMustBeSaved);
end;

procedure TMyComponent.ReadMyRect(Reader: TReader);
begin
  with Reader do begin
    ReadListBegin;
    FMyRect.Left:=ReadInteger;
    FMyRect.Top:=ReadInteger;
    FMyRect.Right:=ReadInteger;
    FMyRect.Bottom:=ReadInteger;
    ReadListEnd;
  end;
end;

procedure TMyComponent.WriteMyRect(Writer: TWriter);
begin
  with Writer do begin
    WriteListBegin;
    WriteInteger(FMyRect.Left);
    WriteInteger(FMyRect.Top);
    WriteInteger(FMyRect.Right);
    WriteInteger(FMyRect.Bottom);
    WriteListEnd;
  end;
end;

Cela sauvegardera MyRect en tant que propriété MyRect.

Si vous mettez en flux beaucoup de TRect, vous ne voudrez probablement pas écrire ce code chaque fois. L'unité LResources contient un exemple qui montre comment écrire une procédure pour définir une propriété rect : 

 procedure DefineRectProperty(Filer: TFiler; const Name: string; ARect, DefaultRect: PRect);

De cette façon, le code ci-dessus peut être réduit à : 

procedure TMyComponent.DefineProperties(Filer: TFiler);
begin
  inherited DefineProperties(Filer);
  DefineRectProperty(Filer,'MyRect',@FMyRect,nil);
end;

Écrire votre propre composant - Partie 2

L'exemple décrit peut être étendu. Ainsi, nous pouvons employer des propriétés arbitraires avec seulement quelques lignes de code : 

type
  TMyComponent = class(TComponent)
  private
    FID: integer;
    FRect1: TRect;
    FRect2: TRect;
  protected
    procedure DefineProperties(Filer: TFiler); override;
  public
    property Rect1: TRect read FRect1 write FRect1;
    property Rect2: TRect read FRect2 write FRect2;
  published
    property ID: integer read FID write FID;
  end;

procedure TMyComponent.DefineProperties(Filer: TFiler);
begin
  inherited DefineProperties(Filer);
  DefineRectProperty(Filer,'Rect1',@FRect1,nil);
  DefineRectProperty(Filer,'Rect2',@FRect2,nil);
end;

Ce composant peut maintenant être sauvegardé, chargé ou utilisé par Les contrôles RTTI. Vous n'avez pas besoin d'écrire quoi que ce soit d'autre.

Écrire et lire des composants depuis/vers LFM

Consultez les fonctions ReadComponentFromTextStream et WriteComponentAsTextToStream de l'unité lresources pour des exemples.

Écrire et lire des composants depuis/vers XML

Mettre en flux des composants est simple : Consultez l'exemple dans lazarus/examples/xmlstreaming/.

Noms

  • Tous les composants appartenant à un composant (Owner) doivent porter des noms distincts. Il en est de même pour deux fiches possédées par une application ou de deux étiquettes (labels) d'une fiche. Mais deux étiquettes appartenant à deux fiches distinctes peuvent porter le même nom et une fiche peut porter le même nom qu'un de ses enfants.
  • TComponent.Name peut rester vide et vous pouvez avoir plus d'un composant sans nom. TWriter écrira la propriété, mais TReader ne trouvera pas le composant en question si bien que la lecture échouera. Par conséquent, l'inspecteur d'objet de l'EDI ne tolère pas cette situation.
  • Les noms doivent être des identificateurs Pascal corrects (IsValidIdent).
  • Lors d'une référence à d'autres fiches, tous les composants racines (forms, datamodules, ...) référencés eux-mêmes par d'autres (forms, etc.) doivent porter des noms uniques. Ils n'ont pas besoin d'être possédés par l'application, mais le programmeur doit alors par lui-même vérifier que leurs noms sont uniques. Les fiches et les modules de données peuvent être retrouvés grâce à l'objet Screen dans lequel toutes les fiches et tous les modules de données s'enregistrent automatiquement..
  • Vous pouvez créer de nombreuses fiches portant le nom Form1 (par exemple, grâce à TForm1.Create(nil)). Si une Form2 fait référence à Form1.OpenDialog, la première Form1 dans Screen sera utilisée.
  • Une fiche Form1 et un cadre imbriqué peuvent posséder tous les deux un enfant Label1. Quand l'étiquette Label1 sera référencée, ce sera de manière univoque pour la fiche entière, donc en incluant les cadres imbriqués. Il est par conséquent vivement recommandé de donner un nom unique à chaque élément.
  • Correction globale : TReader lit le flux d'un composant. S'il rencontre un cadre imbriqué, un second TReader est créé afin d'en lire le flux. Ensuite, le lecteur retourne à son point de départ et continue la lecture. Les référence à d'autres composants (par exemple Form1.Button1) sont enregistrées dans une liste de correction dans les classes des unités (Voir GetFixupReferenceNames). Les références sont rectifiées après la lecture.
  • TReader et TWriter utilisent le nom spécial Owner pour se référer au propriétaire en cours.

Conclusion

La RTTI est un mécanisme puissant qui peut être employé pour facilement mettre en flux des classes entières et qui évite d'écrire beaucoup de code de chargement/enregistrement pénible.

Voir également :

Les contrôles RTTI

Retrieved from "https://wiki.freepascal.org/index.php?title=Streaming_components/fr&oldid=110046"