Création de composant épisode 4

Version imprimable

Bonjour,
Je croyais mon composant TNameFileImage réglé mais, le fait d'avoir changé de poste, réinstallé Delphi etc.. suite au crash de mon défunt PC en testant à nouveau j'ai un problème RTTI

Je dois convertir un string en TFileName et vice-versa pour cela j'ai écrit ce convertisseur
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 initialization TValueRefConverterFactory.RegisterConversion(TypeInfo(String), TypeInfo(TFileImage), TConverterDescription.Create( procedure(const I: TValue; var O: TValue) begin if I.isType<String> then O := TFileName(I.ToString) else O := String(I.ToString); end, 'NomFichierImageToString', 'NomFichierImageToString', EmptyStr, True, EmptyStr, nil) ); finalization TValueRefConverterFactory.UnRegisterConversion(TypeInfo(String), TypeInfo(TFileImage));
Mon problème je ne sais pas trop où mettre cette déclaration dans le partie (unité) design ou dans l'unité d'enregistrement (runtime ?)
Actuellement dans la partie "design" le composant fonctionne très bien dans l'EDI par contre à l'exécution :bug:

Citation:

Erreur
---------------------------
EvalError dans LinkControlToField1 : Incapable de trans-typer ou de trouver des convertisseurs entre les types string et TBitmap.

Cela indiquerai donc qu'il faudrait que je mette cette déclaration dans la partie enregistrement j'ai tenté mais même punition ! sauf à indiquer dans ma liste des uses
uses .., ImageFileFMX,regImageFileFMX; soit les deux unités (alors que quand je pose le composant seule l'unité ImageFileFMX se mette automatiquement)

la bonne option semblerait donc de mettre ce convertisseur dans l'unité enregistrement. Sachant que le composant est dual framework VCL/FMX n'y aura t-il pas un soucis ?

Mon soupçon se porte sur ma méthode de création de paquets, ne faudrait-il pas que je crée un paquet designtime et un paquet runtime ? c'est là où je sèche comment fait-on ça "proprement" (c.a.d. pour une installation facile) ?

09/03/2019, 08h57
SergioMaster

1 pièce(s) jointe(s)

Relance du sujet

Bonjour,

Je pense avoir trouvé où mettre le convertisseur, du moins n'ai-je plus l'erreur d'incapacité de trans-typage !
En fait, pour l'erreur, je cherchai un moyen de changer le type reconnu (TPicture pour VCL/TBitmap pour FMX), j'ai plutôt simplement changer la déclaration, au prix de l'ajout d'unité dans la liste des uses.

Reste un souci :aie:, le dernier coup de collier avant de finaliser.

Ce composant en VCL fonctionne parfaitement aussi bien au design qu'à l'exécution cependant en FMX (j'ai créé un composant qui accepte les deux frameworks) j'ai un problème à l'exécution avec la liaison rapide.

Une vidéo valant mieux qu'un long discours (vous excuserez les clics :oops:)
http://serge-girard.developpez.com/t...MX_edit_2.webm
Il est rageant que je doive écrire : "Attention, vous devez absolument faire un lien manuel pour lier ce composant".

Ma question est donc la suivante quelle différence entre le composant VCL et le FMX pourrait-il y avoir :koi: surtout que, à part la partie Register, c'est la même unité ImageFile.pas

Question subsidiaire : Pour l'instant j'ai mis les procédures d'enregistrement/dé-enregistrements dans les sections initialization/finalization , je me demande s'il ne serait pas possible (pertinent) de les mettre dans les évènements OnCreate et OnDestroy du composant ?

Merci à ceux qui auraient joué au jeu des 7 erreurs dans mes sources.
PS. Je n'ai pas mis les projets tests, ni les sources deux .bpl, trop de dépendances avec des répertoires (installation) ou fichiers externes (images) m'en empêche pour l'instant

Bonjour,

Eurêka ! Tout se joue dans le convertisseur, pas encore tout à fait au point puisqu'il va me falloir gérer l'exception du LoadFromFile mais c'est un détail après ces mois de galère
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 TValueRefConverterFactory.RegisterConversion(TypeInfo(String), {$IFDEF FMX} TypeInfo(TBitmap){$ELSE} TypeInfo(TPicture){$ENDIF}, TConverterDescription.Create( procedure(const I: TValue; var O: TValue) begin if I.isType<String> then {$IFDEF FMX} TBitmap(O.AsObject).LoadFromFile(I.ToString) {$ELSE} TPicture(O.AsObject).LoadFromFile(I.ToString) // O:= TFileName(I.ToString) {$ENDIF} else O := String(I.ToString); end, Convertisseur, 'ImageFile', EmptyStr, True,EmptyStr, nil ) );
Maintenant il va falloir que je comprenne pourquoi ce sont des TBitmap ou TPicture ( {$IFDEF FMX} TypeInfo(TBitmap){$ELSE} TypeInfo(TPicture){$ENDIF} ) qui sont "capturés" par la liaison de type TLinkControlToField et non la classe que j'ai créée :arf:
et voir s'il n'y va pas y avoir des conséquences inattendues si je rajoute une liaison avec une image contenue dans un blob

D'où la question du jour très "RTTI esque" comment retrouver le point de départ (mon composant) dans mon convertisseur ?

Votre opinion

Bonjour,

voici plusieurs versions de mon convertisseur pour la partie VCL , d'après vous quelle est la plus adaptée, à moins qu'il y ait mieux ? Les RTTI et moi ce n'est que le début :roll:

version 1 : la plus simple sans garde-fou

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
procedure RegisterConverter;
begin
  if not TValueRefConverterFactory.HasConverter(Convertisseur) then
  begin
    TValueRefConverterFactory.RegisterConversion(TypeInfo(String),
      TypeInfo(TPicture),
      TConverterDescription.Create(
      procedure(const InValue: TValue; var OutValue: TValue)
      begin
         try 
               TPicture(OutValue.AsObject).LoadFromFile(InValue.ToString); 
         except 
             TPicture(OutValue.AsObject).Graphic := nil; 
         end;
      end,
      Convertisseur, 'U_VCLRunTime', EmptyStr, True, EmptyStr, nil));
  end;
end;

version 2 : inspirée de l'unité Vcl.Bind.DBEngExt

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
procedure RegisterConverter;
begin
  if not TValueRefConverterFactory.HasConverter(Convertisseur) then
  begin
    TValueRefConverterFactory.RegisterConversion(TypeInfo(String),
      TypeInfo(TPicture),
      TConverterDescription.Create(
      procedure(const InValue: TValue; var OutValue: TValue)
      var LOutObject : TObject;
      begin
          LOutObject := OutValue.AsObject;
          Assert(LOutObject <> nil);
          Assert(LOutObject is TPicture);
          TPicture(LOutObject).Graphic := nil;
          Assert(InValue.IsEmpty);  // cette assertion est la plus gênante, Utile ?  
          try TPicture(LOutObject).LoadFromFile(InValue.ToString); except end;
      end,
      Convertisseur, 'U_VCLRunTime', EmptyStr, True, EmptyStr, nil));
  end;
end;

version 3 idem mais avec FileExists (utile ?)

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
procedure RegisterConverter;
begin
  if not TValueRefConverterFactory.HasConverter(Convertisseur) then
  begin
    TValueRefConverterFactory.RegisterConversion(TypeInfo(String),
      TypeInfo(TPicture),
      TConverterDescription.Create(
      procedure(const InValue: TValue; var OutValue: TValue)
      var LOutObject : TObject;
      begin
          LOutObject := OutValue.AsObject;
          Assert(LOutObject <> nil);
          Assert(LOutObject is TPicture);
          TPicture(LOutObject).Graphic := nil;
          Assert(FileExists(InValue.ToString));  // Utile ?
          try TPicture(LOutObject).LoadFromFile(InValue.ToString) except end; // cela peut ne pas être un format image connu
      end,
      Convertisseur, 'U_VCLRunTime', EmptyStr, True, EmptyStr, nil));
  end;
end;

14/04/2019, 09h59
SergioMaster

2 pièce(s) jointe(s)

Besoin de Testeurs

Re,

Voici donc les sources du composant dual (c'est-à-dire aussi bien VCL que FMX)
J'ai besoin de testeurs pour :
1- Savoir si le zip contient le nécessaire (voire du superflu).
2- Savoir si vous réussissez à l'installer.
3- Savoir si le comportement est correct.

Je rappelle l'objectif : lier (LiveBindings) une Image à une chaine (chemin et nom de l'image) que cette chaine soit une simple zone de saisie (ce que je n'ai que peu testé), soit un combobox (mes tests android), soit une colonne dans une table comme dans cet exemple :
Pièce jointe 466616

Cette dernière version est compilée avec RIO 10.3.1 mais j'avais commencé le composant avec TOKYO (Oui, j'ai galéré un an avant de trouver enfin de quoi il retournait !)
Reste que je n'ai aucun moyen, de tester tout ce qui concerne les produits du pommier

N.B. Il y a encore du "déchet" dans les sources du composant (en particulier dans les unités Regxxxxx) la déclaration les convertisseurs y sont totalement inutiles

j'ai lu en diagonal, mais si je comprend bien tu ajoutes à LiveBinding la conversion d'un String en image par un LoadFromFile, c'est donc en Runtime, puisque ce doit être possible à l'exécution (le DesignTime c'est pour ce qui se fait dans l'IDE, éditeur de propriété par exemple).

la version 3 est mieux, mais les assertions sont des contrôles du code que l'on place pour vérifier que ce qu'on pense être le cas l'est bien...Et une option de compilation permet de supprimer toutes les assertions, c'est donc un outil de débogage.

dès lors le FileExists ne devrait pas être une assertion mais une condition au chargement de l'image (ce qui est aussi gérée par le try/except de toute façon)

les deux autres Assert sont des bretelles puisqu'on précise dans le RegisterConversion qu'on a affaire à un TPicture, on a donc théroriquement "LOutObject <> nil" et "LOutObject is TPicture", d'ailleurs le premier est superflus car nil n'est pas un TPicture; mais c'est bien l'objet d'une assertion de vérifier que ce qu'on pense vrai l'est bien.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 procedure RegisterConverter; begin if not TValueRefConverterFactory.HasConverter(Convertisseur) then begin TValueRefConverterFactory.RegisterConversion(TypeInfo(String), TypeInfo(TPicture), TConverterDescription.Create( procedure(const InValue: TValue; var OutValue: TValue) var LOutObject : TObject; begin LOutObject := OutValue.AsObject; Assert(LOutObject <> nil); Assert(LOutObject is TPicture); TPicture(LOutObject).Graphic := nil; if FileExists(InValue.ToString) then try TPicture(LOutObject).LoadFromFile(InValue.ToString) except end; // cela peut ne pas être un format image connu end, Convertisseur, 'U_VCLRunTime', EmptyStr, True, EmptyStr, nil)); end; end;

14/04/2019, 11h47
SergioMaster

Bonjour,

Citation:

Envoyé par Paul TOTH

j'ai lu en diagonal, mais si je comprend bien tu ajoutes à LiveBinding la conversion d'un String en image par un LoadFromFile,

Oui

Citation:

c'est donc en Runtime, puisque ce doit être possible à l'exécution (le DesignTime c'est pour ce qui se fait dans l'IDE, éditeur de propriété par exemple).

et non, à cause des Livebindings. Au designtime les liaisons sont actives et fonctionnent comme s'il s'agissait du runtime

Citation:

mais les assertions sont des contrôles du code que l'on place pour vérifier que ce qu'on pense être le cas l'est bien.

Comme je l'ai indiqué j'ai repris les assertions à partir d'un source de la bibliothèque, je pense qu'elles jouent surtout au designtime quand on est sur le concepteur visuel

Citation:

dès lors le FileExists ne devrait pas être une assertion mais une condition au chargement de l'image (ce qui est aussi gérée par le try/except de toute façon)

C'est pour cela que je me posais la question de l'utilité du FileExists qui, je n'ai pas vérifié, est certainement déjà traitée via le LoadFromFile
14/04/2019, 21h06
pprem

J'ai pu l'utiliser sous Mac et Windows pour la version FMX.

L'installation du paquet ne pose pas de soucis. L'ajout sur une fiche en liaison avec un TFDMemTable prérempli d'un champ String est ok. L'affichage se passe correctement quand on a le bon chemin d'accès.

En revanche ça ne se lainera pas avec un TLabel (qui est unidirectionnel). Et il refuse un TEdit.

https://zupimages.net/up/19/15/xy0n.png
14/04/2019, 23h09
Paul TOTH

Citation:

Envoyé par SergioMaster

Bonjour,
et non, à cause des Livebindings. Au designtime les liaisons sont actives et fonctionnent comme s'il s'agissait du runtime

oui mais le runtime est disponible aussi en designtime, par contre le designtime n'a pas vocation à fonctionner en runtime :)

Citation:

Envoyé par SergioMaster

Comme je l'ai indiqué j'ai repris les assertions à partir d'un source de la bibliothèque, je pense qu'elles jouent surtout au designtime quand on est sur le concepteur visuel

c'est directement lié aux options de compilation DEBUG/RELEASE (ou personnalisé), ce n'est pas une question de runtime/designtime qui concerne les paquets, notamment le paquet DesignIDE n'est pas disponible en runtime et si tu veux y faire référence il faut utiliser un paquet de design.

Citation:

Envoyé par SergioMaster

C'est pour cela que je me posais la question de l'utilité du FileExists qui, je n'ai pas vérifié, est certainement déjà traitée via le LoadFromFile

je ne pense pas que ce soit testé, mais tu te chopes une exception sur la création du TFileStream sur un fichier qui n'existe pas
15/04/2019, 07h53
SergioMaster

Bonjour,

Citation:

Envoyé par pprem

J'ai pu l'utiliser sous Mac et Windows pour la version FMX.
L'installation du paquet ne pose pas de soucis.

Génial, cela veut donc dire que mon zip contenait le nécessaire merci Patrick :troll: Paris avec un ciel bleu ! Cette photo doit dater :/troll provincial:

Citation:

En revanche ça ne se liera pas avec un TLabel (qui est unidirectionnel). Et il refuse un TEdit.

Ah, il faut que j'y réfléchisse en ce qui concerne le TEdit j'avoue avoir planché sur les liaisons avec une table et testé aussi un Combobox.

@Paul je finis par m'y perdre :roll:

Citation:

, notamment le paquet DesignIDE n'est pas disponible en runtime et si tu veux y faire référence il faut utiliser un paquet de design.

lors de mes nombreux essais (largement entrecoupés de pauses parce que ça me gavait) je m'étais aussi penché sur l'utilisation ou non de DesignIDE. Diverses suppressions de code plus tard j'en avais déduit que c'était inutile mais je me trompe peut-être !
15/04/2019, 08h23
pprem

Citation:

Envoyé par SergioMaster

Génial, cela veut donc dire que mon zip contenait le nécessaire merci Patrick :troll: Paris avec un ciel bleu ! Cette photo doit dater :/troll provincial:

tseu tseu tseu... même pas vrai, il fait beau sur Paris, même si cette photo provient de Fotolia :ptdr:

juste un truc, il a fallu que je mettre le chemin des sources du composant dans le chemin de recherche du projet pour que ça compile et idéalement en "toutes les plateformes/configurations". (logique, mais à souligner dans la doc/le tuto)
15/04/2019, 09h33
SergioMaster

1 pièce(s) jointe(s)

Re,

Citation:

Envoyé par pprem

juste un truc, il a fallu que je mette le chemin des sources du composant dans le chemin de recherche du projet pour que ça compile et idéalement en "toutes les plateformes/configurations". (logique, mais à souligner dans la doc/le tuto)

Ah oui, c'est vrai que la partie installation reste un machin un peu compliqué, les chemins de recherche ça fait toujours grimper aux rideaux, je me demande comment font les vendeurs de composants pour que l'on n'ait pas besoin de le faire :koi: une modification des variables d'environnement ?
Et, oui, il s'agit d'un tuto qui traîne par ma faute, je voulais absolument réussir la liaison avec les données sans avoir à passer par un lien "manuel".
Je ne pensais pas le mettre en composant à installer mais c'est vrai que ce serait sympa pour la communauté (sauf que je ne vois pas comment m'y prendre :mouarf:)

Pour ce qui est du TEdit, après y avoir réfléchi, c'est "normal" pour l'instant (j'espère qu'un jour ce ne sera plus le cas) LiveBindings ne permet pas de lier les propriétés entre contrôles il faut avoir recours à une astuce le passage par l'intermédiaire d'un PrototypeBindSource (ou peut être d'une seule de ses composantes)
Pièce jointe 466811
Bémol que j'avais déjà notifié dans un de mes billets du 01/09/2018
Il y a peut-être d'autres solutions, je pense par exemple aux ScopeMappings mais je ne vois pas où cela pourrait s'insérer :calim2:

1 pièce(s) jointe(s)

Pour en finir, voici une image qui montre comment l'on peut lier des composants entre eux
Pièce jointe 468143
restait un truc, le petit bouton permettant de faire la sélection d'une image dans un répertoire : Comment faire l'interaction ?

Écrire quelque chose comme if opendialog1.execute then edtnomfichier.text:=Opendialog1.Filename semblait la bonne idée mais :bug:
il faut passer par une modification de la source de données ainsi
Code:

1 2 3 4 5 6 7 8 9 10 procedure TForm31.SpeedButton1Click(Sender: TObject); begin if FileOpenDialog1.execute then begin // modification de la source de données AdapterBindSource1.Edit; AdapterBindSource1.InternalAdapter.FindField('Field1').SetTValue(FileOpenDialog1.FileName); AdapterBindSource1.Post; end; end;

18/04/2019, 17h18
Thierry Laborde

Salut,

Citation:

Envoyé par SergioMaster

Ah oui, c'est vrai que la partie installation reste un machin un peu compliqué, les chemins de recherche ça fait toujours grimper aux rideaux, je me demande comment font les vendeurs de composants pour que l'on n'ait pas besoin de le faire :koi: une modification des variables d'environnement ?

Tout simplement à l'installation du composant en mettant à jour la base de registre. Par exemple pour la plateforme Win32 sur RIO (Tu trouveras facilement les autres en regardant la clé de la base de registre) :

\HKEY_CURRENT_USER\Software\Embarcadero\BDS\20.0\Library\Win32\Search Path
19/04/2019, 07h12
SergioMaster

Merci Thierry.

Même si mon but n'est pas de distribuer ce composant c'est bon à savoir ;)
Tant qu'à faire j'ai donc une dernière question comment distribuer le paquet sans les sources, et dans ce cas, que fournir ? J'avoue n'avoir jamais chercher à le savoir mais tant qu'à faire autant aller jusqu'au bout !
Et, si quelqu'un à une piste de documentation/vidéo ou autre pour m'indiquer comment faire la distinction entre ce qui doit faire partie d'un composant designtime d'un composant runtime je suis aussi preneur car je nage en pleine confusion sur ce point précis.
19/04/2019, 09h01
pprem

Citation:

Envoyé par SergioMaster

Merci Thierry.

Même si mon but n'est pas de distribuer ce composant c'est bon à savoir ;)
Tant qu'à faire j'ai donc une dernière question comment distribuer le paquet sans les sources, et dans ce cas, que fournir ? J'avoue n'avoir jamais chercher à le savoir mais tant qu'à faire autant aller jusqu'au bout !
Et, si quelqu'un à une piste de documentation/vidéo ou autre pour m'indiquer comment faire la distinction entre ce qui doit faire partie d'un composant designtime d'un composant runtime je suis aussi preneur car je nage en pleine confusion sur ce point précis.

Pour la distribution il faut le paquet compilé (BPL) pour l'import dans l'EDI et les DCU des différentes plateformes si tu ne veux pas transmettre les sources.
19/04/2019, 11h58
Thierry Laborde

Citation:

Envoyé par pprem

Pour la distribution il faut le paquet compilé (BPL) pour l'import dans l'EDI et les DCU des différentes plateformes si tu ne veux pas transmettre les sources.

Attention, comme le précise Patrick, il faudra que tu fournisses les BPL pour chaque plateforme et également les versions 32 bits et 64 Bits pour Windows.

Pour la différence Package Designtime et Package Runtime. Le package Designtime va te permettre de définir des choses spécifiques à l'utilisation dans l'IDE, lors de la conception. Tu n'as pas d'obligation de différencier les 2 et tu peux te passer de packages Designtime et tout mettre dans le même package. Mais prenons un exemple. Un éditeur fait un composant dans lequel il veut inclure beaucoup de spécificités lors de la conception. par exemple un click avec le bouton droit sur le composant et des menus spécifiques qui vont lancer des wizards ou autres écrans et menus qui vont permettre à l'utilisateur à la conception de définir le comportement et les propriétés du composant.
Afin d'éviter de surcharger le composant il sera préférable dans ce cas là de définir toute cette partie là dans le package Designtime afin que tout ce code là ne soit pas automatiquement intégré dans le source du projet développé avec ce composant.
Maintenant rien n'empêche de tout intégrer dans un seul package. C'est plus une question de séparation ou pas de la partie conception lors de l'utilisation du composant avec la partie de code pure du fonctionnement du composant.
Je ne sais pas si c'est assez clair ?
19/04/2019, 14h08
SergioMaster

Citation:

Envoyé par Thierry Laborde

Je ne sais pas si c'est assez clair ?

Si, suffisamment en tout cas, j'en vois parfaitement l'utilisation dans le second composant que j'envisage d'écrire. Déjà commencé mais mis de côté (https://www.developpez.net/forums/d1...y-tcollection/) jusqu'à présent : l'équivalent de TDBRadioGroupBox pour FMX, j'ai pu remarquer que cela n'existait pas et dès que l'on dépasse deux possibilités cela devient c...t d'établir les liens pour chaque !
Je voulais empêcher l'ajout d'autres éléments que des boutons radio dans ce qui me servira de conteneur, cela correspond parfaitement je pense à une partie Design.

Dès que j'aurais achevé ce tutoriel qui, ayant trainé couvre deux versions de Delphi et une foultitude d'essais, nécessite une relecture du code et images que j'ai pu faire, je m'attellerai à cette deuxième partie. L'avantage c'est que dans le premier j'aurais couvert l'écriture de composant "mixte" et que la seconde couvrirait la partie designtime/runtime. Pour un peu, un troisième volet, le déploiement, ferait un joli plus ... À envisager :roll: je n'ai rien lu de tel jusqu'à présent.

Merci