Discussion :

[nicolas.bbs]

Bonjour,

Le sujet est un peu large et je m'en excuse. J'aurais peut-être dû créer un sujet par problème, mais les sujets sont liés et répéter le contexte à chaque fois n'était pas terrible non plus...

Alors voilà le contexte : j'ai créé il y a longtemps un jeu de composants visuels et non visuels en VCL (Delphi 6 à l'époque, et cela comportait essentiellement un package runtime et un package designtime...).
Depuis j'ai porté tout ça sous Delphi XE10.2, et j'ai réorganisé mes packages pour rendre les compos non visuels indépendants du Framework VCL ou FMX (je prévois d'ailleurs d'ajouter des compos visuels FMX plus tard).
Le tout est multi-plateforme Win32, Win64, Android (et un jour probablement iOS).
La structure actuelle de mes packages est la suivante :
- packageCore : contient les compos non visuels, tous indépendants du framework et multi-plateforme
- packageVCL : contient les compos visuels développés en VCL, dispos en Win32 et Win64. Requiert packageCore
- packageDT : contient bien sûr le recensement des compos, mais aussi des éditeurs de composants. Requiert packageCore et packageVCL

1ère interrogation : pour que l'EDI indique "plateformes supportées : Win32, Win64" sur mes compos, j'ai été obligé d'ajouter Win64 aux plate-formes cibles du packageDT (je ne sais plus si la compilation a été nécessaire). Je ne trouve pas ça logique, dans la mesure où ce package ne contient que du code destiné à s'exécuter dans l'EDI qui est 32 bits...
Pire : pour voir apparaître Android dans la liste des plateformes supportées, faut-il que j'ajoute Android au packageDT ? Si je fais ça Delphi m'indique que ça peut provoquer des résultats inattendus, car le framework VCL est utilisé dans ce package... Je n'ai pas essayé de confirmer. Mais de toute façon j'image la suite des problèmes : le paquet requis packageVCL n'est pas compilé en Android (aucune raison de le faire, la plate-forme n'est même pas ajoutée), il va falloir mettre des $IfDef partout pour espérer compiler packageDT en Android (et pour quoi faire ?), et enfin comment indiquer que les composants du paquet packageVCL ne sont alors pas dispos en Android ?
J'imagine qu'il doit y avoir un autre moyen de déclarer les plateformes compatibles pour un composant ?

2ème interrogation : IMPLICITBUILD et la compilation des 3 packages...
Je constate un comportement bizarre : admettons que je compile packageCore et packageVCL en Win32. D'abord le packageCore en Debug puis en Release (-> les dcu vont dans les sous-dossiers Win32\debug et Win32\Release du projet), puis le packageVCL (-> mêmes dossiers pour les dcu). La compilation de packageVCL provoque l'écrasement/recompilation des unités de packageCore. Cela est dû à l'option IMPLICITBUILD, ça OK, mais il me semble que tant qu'il n'y a pas de changement dans les sources de packageCore, il ne devrait pas recompiler. Ce point n'est pas encore très gênant (et c'est peut-être parce que je fais "construire" plutôt que "compiler"). Ce qui est beaucoup plus gênant, c'est qu'en compilant packageVCL en configuration Debug, il écrase les unités debug du packageCore par des versions qui semblent être des release ! Oui oui, je dis bien qu'il met des fichiers dcu en configuration release dans le dossier debug, et il s'agit de toutes les unités recompilées du packageCore requis à cause de la directive IMPLICITBUILD !
Les symptômes qui me font arriver à cette conclusion sont que je ne peux pas déboguer packageCore dans une application test si j'ai compilé packageVCL en dernier : les points d'arrêt sont désactivés. Et la taille des dcu de packageCore dans Win32\debug n'est pas normale : elle est presque identique à celle des dcu de Win32\release. Si je recompile packageCore en débug à nouveau, le problème est réglé (et les dcu de débogage sont alors plus gros).

Pourtant je n'ai pas ce souci avec un autre packageUtilitaires requis par packageCore et packageVCL... La seule différence que j'ai trouvé : packageUtilitaires a son propre dossier de projet, alors que les sources de mes 3 paquets packageCore, packageVCL et packageDT sont dans le même dossier. Et ça m'arrangerait de les conserver ainsi, pour ne pas avoir à mettre 50 dossiers dans les chemins de bibliothèque de Delphi. Avez-vous déjà constaté ce genre de problème ?
Cela m'a amené a regarder la directive {$IFDEF IMPLICITBUILDING This IFDEF should not be used by users}, mais justement celle-ci contient {$DEFINE DEBUG} dans mes projets (ce qui n'est pas forcément logique, mais qui va plutôt à l'opposé du phénomène constaté). J'imaginais de toute façon que les directives du packageVCL étaient transmises au compilateur pour la compilation implicite du packageCore, car il me semble avoir été obligé d'ajouter aux options du packageVCL, des définitions de noms qui concernaient packageCore.

J'ai alors essayé de tout mettre dans un groupe de projets, mais ça n'a pas l'air de changer grand-chose.
Je précise aussi que j'utilise les commandes "construire" ou "tout construire" plutôt que "compiler" ou "tout compiler". Avec "tout compiler" la reconstruction implicite n'aurait peut-être pas lieu, mais je trouve ça tellement plus prudent de tout reconstruire quand on modifie une unité dans un package... J'en suis donc réduit à tout reconstruire dans l'ordre des dépendances pour avoir tous les bpl des packages correctement liés, puis je reconstruis dans l'ordre inverse pour obtenir mes dcu de débogage ! Pas pratique du tout, surtout quand je fais évoluer le package régulièrement et le teste à chaque petite modif !

Merci d'avance pour votre aide.

[SergioMaster]

Bonjour,

étant en train d'écrire un tutoriel sur justement la création de composants VCL/FMX je peux répondre a certaines de ces questions par contre j'en ai d'autres auxquelles je n'ai pas encore de réponse.
Tout d'abord, en ce qui concerne Androïd (ou FMX de manière plus générale) le framework n'étant pas le même que VCL, certaines unités doivent être changées.
Il faut donc un bpl (et donc un projet) FMX séparé de celui du package VCL. Je ne parle même pas des variables tels que positions etc ...

Tout est expliqué dans mon tutoriel (en relecture technique) mais qu'il va falloir que je travaille encore. J'ai quelques problèmes sur les noms à utiliser, sur le fait d'avoir séparé la partie register de la partie composant sensu-stricto et le fait que je doivent inclure les deux unités dans la clause uses

Le lien de départ pour l'écriture de composant FMX

Le lien qui m'a beaucoup aidé pour la partie dualité VCL/FMX

Je peux bien évidemment proposé un pdf (qui lui, sera en français ) de ce que je suis en train de pondre même s'il est encore semble t-il truffé de petites erreurs
dont les deux problèmes cités plus haut

J'imagine qu'il doit y avoir un autre moyen de déclarer les plateformes compatibles pour un composant ?

Oui, [ComponentPlatforms(pidWin32 or pidWin64 or pidAndroid)] au dessus de la déclaration de classe

en cas de composants dual il faudra aussi ajouter dans la partie register des instructions comme
GroupDescendentsWith(TMyComponent, Fmx.Controls.TControl); // pour FMX
GroupDescendentsWith(TMyComponent, Vcl.Controls.TControl); // pour VCL

etc...

P.S. pour obtenir une préversion (MP avec adresse email pour que je puisse joindre le PDF, mais je ne veux pas mettre ce PDF en Pièce Jointe dans ce post)
j'apprécierai d'ailleurs fortement la critique car vous semblez être rodé à l'écriture de composant, contrairement à moi (j'avoue, je patauge)

[nicolas.bbs]

Bonjour SergioMaster,

Merci pour votre réponse, qui résout parfaitement la moitié de la question : celle de la déclaration des plateformes compatibles.
Pour GroupDescendentsWith je savais déjà, et mes compos non visuels fonctionnent même déjà sur Android ! C'était juste ce détail sur les plateformes déclarées qui me chagrinait. C'était tout bête mais il fallait le savoir.

Du coup je n'ai pas pris le temps de regarder les vidéos (malheureusement le temps me manque).
En revanche je vous envoie un MP pour vous proposer une relecture de votre tuto, ce sera avec plaisir et je risque d'apprendre des choses, car même si oui je fais des compos depuis longtemps, ça reste tout de même relativement limité question difficulté technique (compos non visuels, les compos visuels sont dérivés de compos existants je ne crée pas de nouvelle apparence, et je crée des éditeurs de compos très basiques, sans véritablement utiliser les possibilités de l'Open Tools API.

Je laisse le sujet ouvert au cas où une réponse viendrait sur le 2ème problème...

Cordialement.

[SergioMaster]

Re,

Du coup je n'ai pas pris le temps de regarder les vidéos (malheureusement le temps me manque).

c'est compréhensible, surtout qu'elles sont longues

En revanche je vous envoie un MP pour vous proposer une relecture de votre tuto,

reçu, je prépare tout ça (pdf et package) ainsi que la liste de mes questionnements

ce sera avec plaisir et je risque d'apprendre des choses,

je l'espère puisque le composant est observable (livebindings) ce qui amène de nouvelles fonctions et que j'ai buté sur certains sujets peu ou pas indiqués qui introduisent des TValueRefConverterFactory

ça reste tout de même relativement limité question difficulté technique

c'est également mon cas bien que je prévois un troisième volet plus "Style"

sans véritablement utiliser les possibilités de l'Open Tools API.

ça c'est encore un de mes chantiers prévisionnel mais bonjour la complexité !

Serge

[Thierry Laborde]

Bonjour,

je l'espère puisque le composant est observable (livebindings) ce qui amène de nouvelles fonctions et que j'ai buté sur certains sujets peu ou pas indiqués qui introduisent des TValueRefConverterFactory

Le TValueRefConverterFactory permet de créer des procédures de conversion entre différents types dont on aurait besoin dans nos livebinding. Grace aux : TValueRefConverterFactory.RegisterConversion et TValueRefConverterFactory.UnRegisterConversion.

[SergioMaster]

Bonjour Thierry, cela faisait un bail

Oui, je sais ce que cela fait, le hic est plutôt que je ne sais pas où poser ces instructions dans la partie initialization et finalization de l'unité de recensement qui contient la procédure Register ou dans l'unité du composant ?
Bien sûr le problème ne se poserait pas si la procédure register se trouvait dans l'unité du composant du coup j'ai un doute : mettre la procédure register dans l'unité du composant ou bien séparer (ce qui est pour moi plus "naturel")

En te répondant, je me dit que je vais tenter l'option : "mettre initialization et finalization dans le source du composant" pour voir

[Thierry Laborde]

Bonjour Thierry, cela faisait un bail

Oui ça faisait un sacré moment en effet.

Oui, je sais ce que cela fait, le hic est plutôt que je ne sais pas où poser ces instructions dans la partie initialization et finalization de l'unité de recensement qui contient la procédure Register ou dans l'unité du composant ?
Bien sûr le problème ne se poserait pas si la procédure register se trouvait dans l'unité du composant du coup j'ai un doute : mettre la procédure register dans l'unité du composant ou bien séparer (ce qui est pour moi plus "naturel")

En te répondant, je me dit que je vais tenter l'option : "mettre initialization et finalization dans le source du composant" pour voir

Moi ça me semblerait logique de le mettre dans la partie Initialization et finalization dans le source du composant.

[SergioMaster]

Re,

tu as raison, je viens de procéder ainsi et deux problèmes s'envolent
du coup, il ne me reste plus que l'affichage en mode bidirectionnel qui fait des siennes (et question subsidiaire comment bloquer ce dit mode une fois lever le brouillard, mais ça, je crois que je suis passé dessus une fois )