Discussion :

[Invité]

Bonjour,

je regardais cette

. La démarche ressemble énormément à celle que j'ai pratiquée depuis mes débuts avec les TStringGrids de Lazarus en version 0.9. Cette approche ne me dérange absolument pas, au contraire. Cette pratique est une voie royale pour apprendre les rouages de l'IDE, du Pascal utilisé, du compilateur...

Mais j'ai quand même un "petit" doute. En Lazarus le code était en pleine évolution, et c'est normal parce que les StringGrids étaient buggées et limitées. Pour FireMonkey, autant que j'ai pu m'en rendre compte (et pester), les diverses évolutions n'étaient pas toujours compatibles avec les anciennes (XE2, XE7...)

Or avec une telle approche très "composant", on ne peut pas se permettre à chaque évolution de l'IDE d'être obligé, ici pour les TGrid de corriger le code, sauf à recréer sa proposer ligne de composants gérant les versions de l'IDE. C'est ainsi qu'en Lazarus, j'avais créé des TlzLabel, TlzEdit, TlzStringGrid, TlzPostgresConnector et ainsi de suite... Évidemment quand j'ai décidé d'abandonner Lazarus cela a représenté une perte énorme.

Je me demande si oui ou non, il est possible de réaliser des composants sophistiqués avec FireMonkey sans que cela deviennent tellement chronophage que l'on y passe... sa vie. En Lazarus, le système est simple, facile à reproduire composant après composant, facile à maintenir en réalité. Pour FireMonkey, j'ai du mal à comprendre la structure. Évidemment, j'admets que rester compatible avec le développement pour mobile présente un coût. Mais éventuellement, je peux me passer de la partie mobile. Mais qu'en est-il de la partie Linux ? (fmxLinux) dont je ne peux pas me passer ? J'ai quelques mauvais souvenirs de portage de composant Lazarus sur Ubuntu... mais là, on ne contrôle rien dans fmxLinux... et déjà pas grand chose à mon avis dans l'évolution du code de FireMonkey. je sais bien, notamment en mobile, que la durée de vie d'un code est extrêmement limitée -comme celle de son OS d'ailleurs- mais en Desktop on "joue" sur des cycles plus longs... et je ne parle pas que de Windows

Votre avis m'intéresse surtout si comme moi, vous utilisez FMX pour développer du Desktop.
Merci. Gilles

[SergioMaster]

Bonjour Gilles,

J'avoue, je n'ai pas encore vraiment testé un TGrid sous Linux mais je ne pense pas qu'il y ait de difficultés majeures.

Pour FireMonkey, autant que j'ai pu m'en rendre compte (et pester), les diverses évolutions n'étaient pas toujours compatibles avec les anciennes (XE2, XE7...)

c'est vrai que entre XE2 et XE7 il y a eu une grosse progression à ce niveau (apparition des TColumns puis apparition de types de colonnes puis de plus en plus de types de colonnes)

Par exemple la vidéo que tu nous montres est devenue quasi obsolète puisque maintenant il y a un TCurrencyColumn, le truc à en tirer c'est la méthode d'ajout de nouveau types de colonnes.
Cela montre aussi quelque part qu'il n'y a pas besoin de dériver un TGrid pour rajouter un nouveau type de colonne et ça c'est une bonne nouvelle

Je me demande si oui ou non, il est possible de réaliser des composants sophistiqués avec FireMonkey sans que cela deviennent tellement chronophage que l'on y passe... sa vie.

Là c'est une question complexe.
La première question à se poser quand on utilise FMX est tout d'abord est-ce que je ne peux pas utiliser plusieurs composants enfants pour le faire ?
par exemple : au début de FMX (XE2 donc) les boutons ne permettaient aucune image il "suffisait" donc de poser un bouton et d'y ajouter un enfant image (en faisant attention à la propriété Hittest)

une fois cette question abordée, il y a une autre possibilité (ça va te hérisser les poils) modifier le style pourrait-il suffire ?
exemple : Ajouter un bouton de fermeture à un onglet (comme dans un explorateur internet) j'espère que mon petit tutoriel de début d'année va sortir dans pas longtemps

Enfin une fois obtenu la réponse négative à ces deux questions il faut passer à la rédaction d'un nouveau composant , visuel/non visuel, livebindings ou non sont encore des distinctions importantes.

Sans y passer ma vie mais quand même plusieurs week-end, (et avec de grosses interruptions à cause de la 3D à gbgreg) je me suis penché sur deux composants à "créer"
TFileNameImage : un Timage qui serait lié non pas à un blob mais un nom de fichier image
TRadioGroupBox : l'équivalent d'un TDBRadioGroupBox car il n'y en a pas de fait (même chez TMS)
et là oui, c'est galère les deux tutoriels sur le sujet sont loin d'être aboutis ! Mais c'est parce que je suis à la limite de mes compétences n'ayant que peu développé de composants.

TFileNameImage, j'étais assez content de pouvoir écrire que celui-ci était au point jusqu'à ce que je décide de ne plus utiliser un String pour la propriété FileName mais un TFileName. Le mieux est quelquefois l'ennemi du bien, tout a commencé à aller de travers et cela m'a fait plonger du côté obscur des RTTI ! Pourtant j'avais réussi à faire un "dual-composant" (VCL+FMX), il me faut résoudre un seul problème : comment lorsque l'on pose un composant sur une fiche faire en sorte qu'une unité (autre que celle du composant) s'ajoute !

TRadioGroupBox, plus compliqué, là c'est le lien qui me pose soucis . Mes derniers essais fin novembre restaient sur un échec de LiveBinding (mais je crois que tout est résumé dans mes diverses questions dans le forum FMX

Pour en revenir à nos moutons : les grilles, je pensais en avoir presque fait le tour avec le tutoriel Grilles et LiveBindings

mais là, on ne contrôle rien dans fmxLinux... et déjà pas grand chose à mon avis dans l'évolution du code de FireMonkey.

ce n'est pas tant contrôler que s'y retrouver car le code est complexe : il faut jongler entre le code qui gère le "graphisme", les interfaces des parents, les liaisons (livebindings), les styles ( je taquine un peu) et que sais-je encore !
Ce qui me gène actuellement : ne pas savoir quelle couleur par défaut je dois utiliser pour afficher un texte ! ce qui était si facile avec VCL (les couleurs systèmes) n'existe pas en FMX et pourtant ...
exemple tout bête et qui concerne les grilles, un point que j'ai caché (ou plus exactement non abordé car je n'y avait pas pensé dans le tuto indiqué plus haut) : il est possible (par l'intermédiaire des évènements) de changer la position du titre de la colonne et même changer la couleur de fond (une sorte de OnDrawCell de la VCL) seulement voilà le hic, quelle couleur pour le texte ? En VCL on aurait utiliser clWindowsText mais en FMX, alors que l'on peut changer le style au runtime, les risques de se retrouver avec des couleurs non concordantes, voire de se retrouver avec des intitulés quasi invisible sont grands !

Votre avis m'intéresse surtout si comme moi, vous utilisez FMX pour développer du Desktop.

Ce qui est évidemment mon cas, mon projet pour mes dernières années de carrière : migrer toute mon application VCL (une GPAO sur mesure) en FMX et ce en prenant en compte les nouveaux besoins (mobiles si nécessaire), donc pas question de simplement migrer mon application client-serveur VCL+BDE avec des outils existants


Meilleurs vœux pour 2019

Serge